I don’t know what it means to others, but here is a start: Support for .Net
Or how about for starters just making in not flicker like hell.
I like to do a ton of embedding within embedding and this all falls apart no matter how you set the GDI+ and double buffering…
That would be a great one!
+1. I knew I was forgetting something. Must be getting old.
All my web apps are already open. There are plenty of applications to do without this being a problem. Even such a mobile client of a billing application. The customer can enter a quote on your mobile. The quote will then be sent to the server (eg a web application Xojo) when the mobile is connected… No matter the application is decompilable in this case and many others.
In the mobile world, we often are programming by connecting to many external services: address book of the mobile, calendar of the mobile, camera of the mobile, map of the mobile, authentication services via facebook, etc. . The code is simpler than on a desktop application.
It probably goes without saying, but I’d appreciate any example projects people have for “windows flicker” as I’ve learned it’s a broad term with different meanings for different people. They’d be helpful in evaluating (and later, testing) our upcoming Windows plans.
[quote=154390:@Norman Palardy]There’s also some things to consider for Android and how important are they to you
APK’s are dead easy to decompile into some version of source code that can be recompiled. Does that matter to YOU ?
Obfuscation is one option but its still easy to decompile. If so that certainly influences what we would need to do as far as supporting Android. [/quote]
To be candid, I am less afraid of people who can decompile than from people who copycat, whatever RAD they use. None of my software is accredited top level defense anyway 
In the competitive world on apps, algorithms are not so important as the cleverness of the app itself, the ideas behind it. Unfortunately, that cannot be obfuscated. But is not that the case for all apps ? Reverse engineering is often more a question of look and feel than coding.
A figure is of interest : there are approximately 1,300,000 apps in the Play Store, about the same as in iTunes App Store. Seems the ease of decompile has not stopped much people. Is it not the case for VB and VB .NET, by the way ? As far as I know, it never stopped a vibrant industry to be built around it.
[quote]
While its convenient to talk about “Android” (much like it is easy to talk about iOS) the reality if that we would likely have to target some minimum version and not support others the same as we do for any other OS (we do this for OS X, Windows Linux & iOS). Which version would YOU want as the minimum ?[/quote]
The way the Android market is structured, and without much statistics about sales in the Play Store, chances are most of software sales happen for the current crowd of devices in use. Today, it would probably be 4.2. But next year will be yet another one.
[quote=154411:@Brock Nash]@Louis Desjardins I don’t know what it means to others, but here is a start: Support for .Net
Or how about for starters just making in not flicker like hell.
I like to do a ton of embedding within embedding and this all falls apart no matter how you set the GDI+ and double buffering…[/quote]
Actually, .NET is the best and most decent way to alleviate flickering once and for all. But am not too sure about playing matriochkas with containers by piling them. That technique may be valid for Mac, it may not be for Windows. Each platform has it’s inherent limitations, and that should probably not be blamed on Xojo.
Fair - just not every one of our users wants to require people to be connected all the time OR to have an app on a device that can be as simply decompiled
We’ve had people already tell us that
How you architect your app is certainly one of the considerations
Its just one of the things we have to consider about what we could do / should do.
You know, Samsung would probably pay to create Tizen apps with Xojo. Once they roll it out on all their devices, there’s going to be plenty of people in need of software.
On a tablet it could be an issue since a majority is WiFi and not everywhere on the planet yet WiFi is accessible, but on phones, it is less and less frequent to be out of range entirely.
Because iOS Xojo does not have server socket, I will be forced to use a web service to install fonts on devices with my next app. For such a feature it should not be a problem. All is a question of what the app is for.
VB is decompilable the same decompile vb.net at DuckDuckGo and from what I see, it has not stopped it from being a rather successful development tool for all these years.
[quote=154390:@Norman Palardy]There’s also some things to consider for Android and how important are they to you
APK’s are dead easy to decompile into some version of source code that can be recompiled. Does that matter to YOU ?
Obfuscation is one option but its still easy to decompile. If so that certainly influences what we would need to do as far as supporting Android.
[/quote]
Making it hibrid could solve this. An obfuscated Java wrapper (using the SDK ProGuard?) and lots of Xojo code in native CPU code (NDK, libs.so). The downside is that with the evolution of the new processors it could demand new compilers and a pure Java binary code is processor agnostic.
[quote=154390:@Norman Palardy]
While its convenient to talk about “Android” (much like it is easy to talk about iOS) the reality if that we would likely have to target some minimum version and not support others the same as we do for any other OS (we do this for OS X, Windows Linux & iOS). Which version would YOU want as the minimum ?[/quote]
As said before, 4.1 is the best start point for 2015, but who knows how long it will take to us to see an alpha? Maybe the Lollipop (5.0) will be the major start point by that time, change it as you go. 
You know, Moblin->Maemo->MeeGo->Tizen->???
I am not waiting. When (or if) they become relevant (I don’t know, 20% of the Android market share?) we should start to look at them. 
That’s the advantage of a native mobile application: you work locally, even if there is no network, and the data is synchronized once the network is available. There is no need to be connected all the time. In my quote app example, the quote is entered on the mobile, and then it is sent to the server once the network is available.
The problem with XOJO web apps is that they can not work offline. We need an offline solution on mobile. And mobile that most people use, so Android.
One solution (at least temporarily) is that web apps can continue to operate even if there is no network and can be compatible with Phonegap (With WebSDK, we can do extraordinary things now). For the network, Greg seemed to say that it was possible, but that it was necessary to cache queries and to overhaul the event transmission system .
Apparently HTTP 1.1 server side would be a great help. But this is not yet implemented in Xojo. And only HTTP 1.1 client side is scheduled. 
Sometimes you have to be pragmatic. Example: Titanium could not offer short term native Windows applications. In the meantime, they propose hybrid windows applications (web apps encapsulated in a native app), it can meet the needs of the market pending. The main one being to have a solution for the customer.
I’ll say ALWAYS be pragmatic. Dogmatism is what kills software. And innovation. And release dates.
A healthy dose of pragmatism is what makes great apps.
Thank you Michel. We had 60% price increase for iOS this year, and we will have 60% more for Android !
Thank you Michel !!
.
[Mode humor off]
Sam, you think Samsung could subvention Xojo to add Android ?
No he wrote about Tizen and not about Android 
I suspect if Xojo contacted Samsung, Samsung would happily pay what ever Xojo wanted to make Tizen apps. Samsung want to get rid of Android, I don’t blame them either, but I’m not sure that Samsung can build a reliable OS.
When even Microsoft was not able to really compete on the phone OS market, I doubt Samsung will be able to create enough momentum for Tizen to replace Android. All they may achieve is to kill their own products for lack of the applications users want. Tizen is a dinosaur in the making.
Just to add a bit spicy of uncertainty:
Samsung has it’s own IDE and tools and people dedicated to maintain it.
Samsung usually solves such kind of thing by themselves using their people. If they have interest in some company, it’s more likely they buy the company than outsource such kind of development.
Samsung has more developers than the entire Microsoft. (and more employees than MS+Apple+Google combined).
As well as its own IDE Tizen is already supported by Cordova, Unity, Cocos2d-x, Marmalade, OpenFL, GameSalad, Appcelerator, Intel XDK, CocoonJS, Project Anarchy, …
On top of that TouchWiz is built on the Enlightenment Foundation Libraries which now has a tool (called Eolian iirc) which enables the auto-generation of bindings for other programming languages. I think the plan is to include Lua bindings and LuaJIT by default.