I am now developing a web application with Xojo, which is great to do. It’s nice and easy, and it will do whatever I need the application to do. However, I notice that with web apps there is one major, if not one only yet important, disadvantage, especially with regards to mobile devices. As soon as the mobile device is disconnected from the internet, you cannot access, not only your data, but also the application itself. For example, I am developing a calendar at this time. If the user wishes to see his appointments or to make an appointment, he can do it as long as he has an open connection to the server. Losing that connection, he can work no longer with his calendar.
Now the advantage with the iOS extension in Xojo is that the user can still save an appointment to his calendar (I guess in sqlite format), although the calendar is not up to date (because it cannot connect to a remote server). This aspect of an application for mobile devices, really, is what makes Xojo so much worth working on the iOS project. I think it is also important to consider that the Android and iOS development must, from this very viewpoint, go hand in hand, because not every user has an iOS device. Therefore the Android project in Xojo is as important and relevant as the iOS, perhaps even more important, since Google will perhaps devour everything else in future.
I can only encourage Xojo for sustaining such developments, and will be happy to hear some news about its continued effort in this.
Another thing which I’d like to add is concerning the breakthrough in the computer world if Xojo comes with such new qualities like the iOS and Android extension. Realbasic was really, I think, a great achievement in the beginning, because it was 1. cross-platform and native to the OS, and 2. a simple, but elegant and powerful way of programming for all OS. Java is cross-patform too, but not native to the OS. C++ is cross-platform and powerful, but very difficult to deal with. This is, of course, my limited understanding of computer languages, although I am able to appreciate the difference which Xojo has with other languages.
Everything else was, since that beginning, only improvements not breakthroughs. Briefly, the ability to developing for mobile devices will, in my opinion, be another revolution by Xojo in the area of computer languages.
I think you could use standard HTML5 features like AppCache and IndexedDB to overcome the issues you describe above rather than having to resort to a native app. Just re-sync your calendar with the server once you’ve got a connection.
I have to confess I’ve never used web edition (I believe it sends every client event to the server, that’s enough to put me off) but I assume this functionality would still be available even if you have to implement some of it directly in JavaScript.
I did not know about the AppCache at all. I will try to implement this in my own web app. Thank you for the links you have provided. They are extremely useful.
Web edition, despite the necessity to stay connected, is a great asset for future native iOS and Android apps, since it uses a page oriented full screen design, just like iOS and Android apps do. So what is learned in GUI design for WE can be applied for iOS.
The same source predicts iPad to make 30% of the tablet share in 2014, with 65% for Android.
Within the Apple family, iPad would then represent 10 times the number of Mac units sold.
I am eagerly awaiting Xojo iOS to be able to move my existing Mac applications to iPad. My hope is that beyond the need to redesign the UI, being able to use the same logic will greatly speed up development.
I have tried Livecode, and it works fine, but the language is much too far from Xojo to be able to use any developed assets, so all has to be rewritten.
Same problem with Basic4Android, which in spite of a superficial similarities with Xojo, is in fact a different language, and requires starting over from scratch.
IndexedDB is useful too, but I’ve just read that it does not support Safari mobile. This is not so good news.
Does this also mean that I will be able to compile more easily in future for iOS from my WE source code which I already have than from what I write for desktop applications?
[quote=125272:@Payam Arzani]IndexedDB is useful too, but I’ve just read that it does not support Safari mobile. This is not so good news.
Does this also mean that I will be able to compile more easily in future for iOS from my WE source code which I already have than from what I write for desktop applications?[/quote]
Pending actual tests, iOS should not be different from what we experience today. You can directly copy and paste methods from Desktop and Web. So all the code in methods should be transferable without modification. If your app has a lot of logic attached to control events, it should still be possible to transfer a lot of it by copy paste.
I have not done it myself, but Bob Keeney shared in another thread that he has done so for desktop applications ported to web that way, and that when conducted patiently, results are good. I would suppose that after all, even if you cannot copy for instance a mouseDown directly, you can always recreate it and copy the content.
The main challenge could be more in UI design more than code. I have started blue print work on porting one of my app from desktop to iOS. The traditional Mac OS menu bar does not exist, so all options in there must be transferred to iOS style controls. PopupMenus are kind of unusual under iOS. Same remark. I use a listbox to mimic a register. Some commands have to be made more evident. And so on.
Transferring a Web App, as I said above, should be less of an issue, since already a web app is closer to the iOS single page, no menu design. And you already know how it reacts on a tablet. So doing the same design on iOS should be more evident.
Aesthetics maybe the biggest hurdle, though. Many iOS apps are extremely modern, and developers seem to put a lot of efforts in stunning visual effects. I am afraid a very basic implementation of standard controls may produce kind of an “old fashion” look, like it happens in Mac OS X.
[quote=125272:@Payam Arzani]
Does this also mean that I will be able to compile more easily in future for iOS from my WE source code which I already have than from what I write for desktop applications?[/quote]
No
The design philosophy is similar but thats where the similarity stops
[quote=125467:@Steve Wilson]“Apple announced forthcoming support in Safari 8 for both iOS 8 and Mac OS X at their WWDC 2014 Keynote on June 2, 2014.”
Source: Wiki Indexed DB[/quote]
Which means that only a portion of the ios user base and a portion of the OS X user base would be able to use it initially
[quote=125468:@Norman Palardy]Which means that only a portion of the ios user base and a portion of the OS X user base would be able to use it initially[/quote]Yes, it’s a shame Safari lags behind in that way. It was the same with WebGL and now with Web Components.
Can iOS users install Chrome? I think I’m right in saying Apple wont allow them to have Firefox.
There are several alternative browsers on iOS - Chrome is one - but they all use the underlying webkit engine
Firefox doesn’t exist on iOS because Apple wont allow alternative browser engines & Mozilla wont put Firefox on iOS unless Apple lets them use their web engine (although if you had a jailbroken device I doubt theres much apple could say about some other web engine)
So they do exist but hey are more the same than different because they all use WebKit
[quote=125477:@Norman Palardy]There are several alternative browsers on iOS - Chrome is one - but they all use the underlying webkit engine
Firefox doesn’t exist on iOS because Apple wont allow alternative browser engines & Mozilla wont put Firefox on iOS unless Apple lets them use their web engine (although if you had a jailbroken device I doubt theres much apple could say about some other web engine)
So they do exist but hey are more the same than different because they all use WebKit[/quote]
Chrome/Opera use a different JavaScript engine to Safari though, don’t they? Presumably that’s where functionality like IndexedDB and WebGL would be implemented.
They do not. All iOS browsers must use WebKit and are not even allowed to use the improved Nitro JavaScript engine, at least for now. Nitro will be available to third party browsers in iOS 8. Safari support for WebGL also starts in iOS 8.