john.allen:
Juan Carlos there is already a request for this. See earlier in this thread.https://support.servoy.com/browse/SVY-4231
Be sure and vote there.
Oops. I didn’t see it. I voted and closed the one I created.
Imho I think what a lot of (or less) Servoy developers want for mobile hardware is the data (foundset / dataset) functionality…
I of course meant foundset directly (on line) connected to back end database.
We added a sample for the new feature to the wiki page at:
https://subversion.servoy.com/examples/ … mple/trunk
It demo’s something like a Fedex/UPS delivery app, that uses a jquery based signature library to display a signature field for a delivery.
I am also very surprised to hear on-line is not possible with mobile. That was what we were thinking of what Servoy 7 would deliver. By on-line I also mean as you say read and write directly to aback office database.
I mean does anyone really want to deal with all the sync mess we had (in the past). One would do that only if absolutely necessary, at least me.
For all other cases, and nowadays there are at many places WLANs accessible. Of course I also understand there are some cases for off-line.
+1 for on-line (obviously .-)
lwjwillemsen:
+1 for on-line access (read and write directly to back office database)I am very surprised
that this is now not possible in mobile client !
please vote on the Jira ticket!
I mean does anyone really want to deal with all the sync mess we had (in the past). One would do that only if absolutely necessary, at least me.
I fully agree with this statement, however, just yesterday, we had a planning meeting with one of our customers that wants to go mobile (mouse breeding for medical research). They want real-time access to the data as the primary use, but they also stated that they want synchronization as a secondary use in case the network goes down. Essentially, they do not want their employees to stop working just because there is no wireless network connection. So, there is still a demand for synchronization.
It demo’s something like a Fedex/UPS delivery app, that uses a jquery based signature library to display a signature field for a delivery.
About 7 years ago, we developed a FEDEX/UPS application for UCSD (University of California, San Diego) which is used across several campus locations. The devleopment tool we used for this was MCL Collection, a Belgium-based company. Although MCL is wireless capable, we had to use synchronization methods, because the campuses were not fully wireless capable. This forced us to limit what the application could do, so there is a drawback to using the synchronization only method. The MCL app ran on Motorola MC50 hand-held units that have a touch screen for signatures with a built-in laser scanner to read package bar codes. Having a wireless connection would have made things much easier. By the way, we are currently re-writing this system in Servoy and would like replace the MC50’s with iPad and Android devices rather than continue with MCL.
I just wanted to throw my observations into the fray…we are seeing an ever increasing demand for real-time wireless applications and hope that Servoy picks up this challenge…soon!
Jan Blok:
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:
-
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.
-
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.
Summary
You 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.
I think that David’s post above is full a really good points. I am not a developer of David’s caliber, and i can’t judge his opinion too deeply.
But I think he’s right for the most part. Servoy already is a good platform to build GUIs. Also, you can easily extend its capabilities. For example, using Patrick Talbot’s Velocity plugin and Twitter Bootstrap, you can easily built HTML 5 applications for mobile devices. I am sure that other Servoy developers can figured how to leverage Servoy’s back-end and REST architecture to build even native applications.
Anyway, David is also right. It’s not a good idea to deviate from Servoy’s instant debugging, export client module, etc.
I wonder what the other star Servoy developers (such as the Patricks, Robert, etc) have to say about the points that David’s raised here.
I think David points were full of positive criticism. Hopefully, we all understand it like that.
Best, Carlos
Thanks David, for sharing your view on the world.
david:
…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.
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.
We agree, thats why we already are working on an html based form editor, Maqetta is in the picture.
Having a fully working mobile client had just more prio then a cool looking mobile editor from day one.
Jan Blok:
We agree, thats why we already are working on an html based form editor, Maqetta is in the picture.
Would love to take a look. Currently I don’t have the requisite super powers to access that ticket though
Still no access to SVY-3659.
Made the case public, but there is not much to see other then we started in January with this.