Jan Blok wrote:Thanks for the case!
If software can work offline, it most certain can work online... other way around is much harder.
As you all of you probably know, the web is currently full of online app builders/tools/frameworks/libs...
In order to have a viable place in the tools world, we needed to focus and driven by more then one customer we found a niche which is offline.
After typing my views on Servoy Mobile for the ump-teenth time on Skype to one more developer....
I think you guys missed the boat entirely on this one. It's like providing an answer to a test question that has nothing to do with the question. No matter how detailed or thorough your answer is, you still don't get any points for it.
Additionally, you stuck a big ole' abstraction layer right in the middle of everything. That's like solving the (wrong) problem with a slide ruler. Huge mistake to toss GWT into the mix.
And I'm sorry, but the mobile editor brings back nostalgic memories of my Commodore 64. The fact that it does work comes as a surprise as one look at your first form and anyone sane is going to run away.
All kinds of approaches that would be way better for what we need as Servoy developers. One suggestion:
1. Formalize the service module concept into a standard REST and routes api for complete record/CRUD/collection operations for all tables on a Servoy server so we don't have to think about this side of things. Ember.js comes to mind.
2. Provide a client-side js library that we can include into any mobile framework. It gives us some Servoy-esque functions (for records and foundsets/"collections") on the client-side and automatically talks to (1.) on the server. Example: extend
backbone.js and have something like "Backbone.Servoy" (see
Backbone.SharePoint).
Stop right here. Don't do an editor. Advanced Servoy developers will push out lot's of mobile apps with these tools (we already are, but REST end points into Servoy is as close as it gets right now).
Wait until the client-side world settles down a bit. And then OF COURSE write the GUI editor in...wait for it...
html. And make it mobile library agnostic. And don't do it yourself -- extend something like
Maqetta.
SummaryYou guys bit off way more than you could do well. The result is something that is not useful in just about any scenario, totally unfinished, not flexible or extendable (no way I'm locking myself into the external js library bean or hand editing output files), locks you into old technology from day 1 (jquery mobile already has a completely new version in beta -- and maybe I'd rather use enyojs or something?), deviates away from Servoy's instant debugging (export client module, activate service module, rinse and repeat...what the hell?), and obscures all the other great features in Servoy 7.
And if I hear again that you released Servoy Mobile in this state because you're "doing it the Agile way"....*SMACK*.
You missed a great opportunity to ease Servoy developers into modern client-side coding. I recommend blowing this edition of Servoy Mobile up and pushing out well-implemented pieces that allow us to keep flexible, stay current and get mobile apps done now. That's doing it the Agile way. No way Servoy can ever implement a complete solution all at once that can compete at this late stage of the game. The fact that you tried has put you even further behind competing technologies.