I’ve made a drawing app which works fine of Mac. I tend to test it on Windows, too.
Now, I’d like to port it to iOS (to be used mainly on my own iPad).
The Mac version is a bit complex (yes, that’s relative…), so porting may be complex as well; on the other hand, Xojo is meant for multi-platform development. And I’ve not done much iOS programming as of yet.
Currently, the desktop version uses a canvas for input (mouse clicks) and drawing (vector and bitmap) and another canvas to pick tools (very similar to the venerable AppleWorks).
Also, there are a lot of commands available from menu items.
I’m hesitant to port to iOS, because it looks like most of the app would have to be rewritten, as many concepts are different.
Just the fact that iOS uses a MobileCanvas and the desktop uses a DesktopCanvas seems a huge amount of work. I’d have to put most logic into a class (shared between both projects) and merely use the MobileCanvas and DesktopCanvas to intercept clicks/touches (passing them straight to a common method in my class) and doing the same for painting (send the paint event to my class). It looks overkill to me that way.
Amen to that.
I’ve tried , but could only make use of non-GUI code.
(= I’d have to put most logic into a class)
Invalidate and refresh work differently.
Theres no real equivalent to right-mouse-button.
And I personally really feel the lack of menus… there are only so many buttons you can put on a screen!
I managed to get a cut-down app built but lacking a lot of features.
(If I was starting again, I wouldn’t use the iOS master/detail principle, in the slight hope of an Android port.
When Xojo manage to ship a stable Android version, the difference in split screen thinking would mean more recoding)
Thank you. Useful reference.
Was putting most logic into a class a lot of work in your case? Would you make it again?
It doesn’t look to be documented. Under the iOS canvas, the “refresh” method just says it marks the canvas as needed to be redrawn (like in desktop). There’s no Invalidate method there.
What is the difference you’re referring to?
Perhaps two-fingers gestures?
Yes, I get that. I’m thinking I’ll put a squared button that, once clicked, contains hierarchical commands similar to a menu. But I already know UI items are different on iOS (there’s no popup menu, for example). Not sure this idea is actually doable.
My guess is, if it’s worth porting to iOS, I’ll attempt an UI in a “temporary” project, possibly restarting from scratch several times, until I find something that visually works. Then I’ll manage to pack the logic into classes and share them between projects and, finally, link the UI and logic. Complex, certainly.
What kind of features were not implementable in your case? (not asking to reveal things about your app, just about areas that caused issues).
That’s also a deep question. If Android support ships “soon” (and is mature enough), it’s better to wait a bit and port to both mobile targets at once. On the other hand, as we don’t know how long it’s going to take, delaying to port for iOS may not make much sense.
Anyway, once the logic is packed into shareable classes, I guess the UI will be slightly less problematic.
I wouldn’t use a Canvas for this as screen space can be quite limited.
You are better off using a scrollable UI element such as ScrollableArea with buttons or ARiOSMobileCollectionView from @Antonio_Rinaldi
The thing is, you got to let go of the typical desktop metaphor. iOS is different, and since you don’t have windows, you must think in terms of a succession of full screen views.
For drawing, this wouldn’t work great (yes, “right click” is sometimes used in the desktop version). But the Apple pencil 2 has a way to toggle the current tool, so that would replace right clicking.
Granted, this will require deep thoughts.
Looks like it won’t be simple. I’ll try at my spare time.
Thanks.
Not to discourage you, but it took me 3 months to port my Desktop Check Writer app to mobile.
Take your time, and don’t try to force unusual UI commands. Most iOS users never read the manual. So if something is not intuitive, you will get bad reviews and angry customers.
Its not intuitive
In desktop, Invalidate means ‘do it when you get around to it’
Refresh means ‘do it now’
In iOS, Refresh is documented to mean ‘do it when you get around to it’, which is equivalent to invalidate, although I have read that there is a way to make it work ‘at once’
The difference is important if you want to move elements around the screen under the control of the mouse/pointer… drag from here to there and you dont want to wait for the object to move with you.
Menus are possible since for iOS14+ using iOSKit
They are either displayed after a single press or long press.
Why is stuff like this NOT part of the Xojo iOS implementation?
It’s not like it has to maintain compatibility with Mac / Windows … iOS is its own thing.
Having to fall back on iOSKit for so much isn’t great.
It’s like buying a car, but only being able to drive it , if you hitch a horse to the front to pull it along.
Was putting most logic into a class a lot of work in your case? Would you make it again?
It’s a logical and sensible technique, and definitely would do the same.
Wish I had started my desktop app in the same manner (I fell into the trap of having UI handle some business logic for example)
A document class holding everything about the graphics, including getter and setter methods, leaves you able to use polymorphism to implement the UI
It can even go so far as to have a picture property , on which the data is rendered, leaving the UI to simply display the current state of that picture in a MobileCanvas ’ paint event
First reason:
Unfortunately, Xojo almost never implements an iOS API that is not available in the minimal Xojo supported iOS version, which is currently iOS11.
I don’t want Xojo to only support iOS14+ because that would cut out 10% of my user base.
Thanks. Actually, I don’t plan to sell this app. But I’ll act as if I would.
I’ll try with this in mind, thanks.
I agree. But, as long as there’s something available for free (and not too cumbersome), I’ll go on.
An easy trap to fall into.
In my case, I didn’t expected to attempt an iOS port, so there’s code in MouseDown/MouseDrag/MouseUp/MouseMoved events of the DesktopCanvas that hold logic. However, it’ll be straightforward to move this into a shared, non UI, class. Rendering is already in a dedicated method (since printing and exporting use the same code than painting) and the shape are already classes.
The reason I’m planning to port to iOS is that I feel most of the requirements are already in place, except the UI (the big part).
Thanks. I’m thinking along those lines.
For the bitmap part, it’s already that way. The vector part, however, will have to be refactored (there’s no fixed-size page notion in this mode, for instance, so for drawing in a picture, I’ll have to add constraints). But I think I’ll try to just pass the graphics object (from both the DesktopCanvas and MobileCanvas) to a shared class (less work).
I also think supporting earlier operating systems is a great thing. But couldn’t Xojo, for instance, raise a UnsupportedOperation exception should one need these recent additions? That would be the best of both worlds.
Ah yes, a lot has been done. At least, you can be proud of your work
FWIW, Xojo’s support of UTF8 characters is awesome! I’m refactoring my tools canvas into a class, at the moment, and the custom events and methods will be redirected to methods of the class (with AddHandler); I’m defining the methods like this:
EVNT→ButtonClicked(Which As CButton)
EVNT→GetState() As Dictionary
MTHD→EnableButtonsForGroup
So I can work in both directions in a single “bridge” class.
I’m giving this as a hint: Xojo’s lack of grouping methods in a given class can easily be worked around by using symbols in methods’ name (as well as properties, etc.).
It took me quite a while because the app is complex, and I needed to implement the mobile UI, which when it comes to phones can require a new thinking because of the small real estate. I found myself using several views instead of single windows.
That said, now that it is done, I do enjoy nice sales in both the App Store and the Play Store. Since Xojo did not have Android, I went to another Basic, but when Xojo Android comes to be, that is a great opportunity, and hopefully API 2.00 will make it easy to go from iOS to Android.
