I need to develop a gwt app that requires support on desktop, mobile, tablet. I need to choose whether to use m-gwt or stick to the approach presented in Google IO 2011
Google IO 2011 approach seems to be -
1) create different views for different screen sizes
2) use deferred binding load only the relevant views according to the user agent
3) same presenter code
IO 2011 approach seems much simpler to me (and not tied with activities and places) but I am not sure if this approach is still popular and will work.
Can someone please let me know the pros and cons of these two approaches ?
Regards,
Sathya
You are mistaken in the assumption that mgwt is tied to Activities & Places, you can use it without using them. If you like using Activities and Places mgwt works of course very well.
The approach presented at Google I/O is actually quite similiar on what mgwt does.
If you are looking into building one application for phone, tablet and desktop from one code base here is an interesting read: http://fahnenbruck.blogspot.de/2014/02/running-on-any-platform-using-java-with.html
Related
I understand from threads in this forum and the Google GWT forum that in the GWT world you typically load just a single page and then what appears to a user to be a different page is just the same page with it's content being updated by user actions. A lot of posts imply that you develop your app as you would a desktop application. That sounds easy if you have done desktop development but I am coming from a pure Web services/ Servlets/ Struts background and want to see a very basic example that shows the proper way to implement a GWT app where you show a user a txt box and button and when they click the button, the view is replaced with 2 different components.
There are plenty of basic apps I have done and plenty of complex multipage type ones but I just one that takes me past the click a button to see a message type app to the next level.
Any links to such an example would be welcome
I recommend to study Activities & Places design pattern. It is the best approach, in my view, for large applications with multiple views. It provides a lot of important functionality "out of the box", like browser history management, support for tokens, efficient memory management, etc.
You may want to look into the Model-View-Presenter pattern (MVP). Using this pattern correctly will greatly decouple your application, allowing you to create views that are not only highly modular and disposable, but are very easy to swap out and change.
In fact, Google fully recommends the MVP pattern when developing GWT applications. They provide a full example and walkthrough of a MVP GWT application here, which I imagine is based off of a Google I/O presentation given on best GWT application architecture practices back in 2009.
I've been following this pattern with my latest GWT project and it's working out extremely well. It's very easy to add, remove and swap views.
This question has been asked in various guises. However. this is a slightly different take on things. By web application, I mean an ultra lightweight frontend - ideally an HTML page with form and regular buttons, with as little dependence on heavyweight JS libraries like jQuery as possible.
The goal is simple. I want to write a simple forms based application for use accross various mobile devices. I thought going the HTML route would be the simpler route (since browsers get around the whole cross platform issue) but even the browser approach seems problematic because of differing screen sizes on mobiles.
I have two questions:
For a simple form based application like I have in mind (possible 3-4 screens in total), I think the browser based approach gives more bang for my buck - am I missing a trick?
Are there any resources that someone can point me to for:
a useful reference for minimum (i.e. lowest common denominator) window size (I forget the technical term for the visible part of a page)
perhaps an example that will show a simple HTML page that will render correctly accross multiple devices?
The HTML5 mobile boilerplate will probably answer a lot of the questions about how to best get things to work across browsers:
http://html5boilerplate.com/mobile/
They have example markup and template implementations for things like browser/device specific CSS hacks, getting a custom launcher icon across different device styles, and implementing offline digest.
You really need to answer two questions before you pick a platform. First, what mobile devices and/or device capabilities are your lowest common denominator? There are lots of variable capabilities between most of those platforms -- screen size, input method, platform speed and mobile platform to name a few. Second, what is your connection requirement? Completely different issue building something targeting spotty or no connectivity versus a fully connected app.
Then you can start thinking about what tool(s) might get you there. In general, a very, very simple HTML site will look okish on most platforms you list. I wouldn't roll with HTML5 functionality because you've got serious limitations there. And HTML/web apps are kind of moot if you need things to work with limited connectivity.
iOS (webkit), Android (webkit) and BB OS6 (webkit-ish), are fairly easy to develop for.
Windows 7 should be, but who knows? They aren't promising HTML5 support until end of year.
BB OS5 browser sucks if you hope to be doing DOM manipulation or fancy JS event listeners. It's really buggy.
Nokia...it's a crap shoot. Granted, they have about one year left before they ditch their OS anyways.
Screen sizes are an issue, as is the fact you can change the orientation. But that can be gotten around with some careful planning.
HTML5/CSS/JS is definitely the way forward for making cross-platform apps as easy as possible...be it in the browser, or as a compiled app.
I am about to start building an app that will be used across all platforms. I will using monotouch and monodriod so I can keep things in .net
I'm a little lazy so I want to be able to reuse as much code as possible.
Lets say I want to create an application that stores contact information. e.g. Name & Phone number
My application needs to be able to retrieve data from a web service and also store data locally.
The MVVM pattern looks like the way to go but im not sure my approach below is 100% correct
Is this correct?
A project that contains my models
A project that contains my views,local storage methods and also view models which I bind my views to. In this case there would be 3 different projects based on the 3 os's
A data access layer project that is used for binding to services and local data storage
Any suggestions would be great.
Thanks for your time
Not specifically answering your question, but here are some lazy pointers...
you can definitely reuse a lot of code across all 3 platforms (plus MonoWebOS?!)
reusing the code is pretty easy, but you'll need to maintain separate project files for every library on each platform (this can be a chore)
MVVM certainly works for WP7. It's not quite as well catered for in MonoTouch and MonoDroid
some of the main areas you'll need to code separately for each device are:
UI abstractions - each platform has their own idea of "tabs", "lists", "toasts", etc
network operations - the System.Net capabilities are slightly different on each
file IO
multitasking capabilities
device interaction (e.g. location, making calls etc)
interface abstraction and IoC (Ninject?) could help with all of these
The same unit tests should be able to run all 3 platforms?
Update - I can't believe I just stumbled across my own answer... :) In addition to this answer, you might want to look at MonoCross and MvvmCross - and no doubt plenty of other hybrid platforms on the way:
https://github.com/slodge/MvvmCross
http://monocross.net (MVC Rather then Mvvm)
Jonas Follesoe's cross platform development talk: Has to be the most comprehensive resource out there at the moment. He talks about how best to share code and resources, abstract out much of the UI and UX differences, shows viable reusable usage of MVVM across platforms and nice techniques for putting together an almost automated build. (yes, that includes a way for you to compile you monotouch stuff on Visual Studio)
Best of all he has a available source code for the finished product and for a number of the major component individually placed in its own workshop project and a 50 + page pdf detailing the steps to do so.FlightsNorway on github
IMO the only thing missing is how best to handle local data storage across all platforms. In which case I would direct you to Vici Cool Storage an ORM that can work with WP7, MonoTouch and (while not officially supported) MonoDroid.
*Disclaimer* The site documentation isn't the most updated but the source code is available. (Because documentation is Kriptonite to many a programmer)
I think the easiest way to write the code once and have it work on all three platforms will probably be a web-based application. Check out Untappd for example.
You can start by looking at Robert Kozak's MonoTouch MVVM framework. It's just a start though.
MonoTouch MVVM
Are there any major advantages/disadvantages I should take into consideration when developing an app which and deciding whether to creates parts (styled menus, pages with content with complex layout etc.) in HTML/UIWebview or doing it all native?
I would like to hear people's experiences with this.
Personally, I find that I tend to dislike web apps that are (usually) disguised as iOS apps. I tend to notice a lot of inconsistencies between the UI of a web app and a 'native' app, and most of the time, it bothers me (my biggest pet peeve is tapping a button and seeing it highlight with a little translucent black box around it like a link). Now, I don't represent the major user demographic, which probably won't care, but that's my personal opinion.
In terms of programming, I've never written a web app before, but I assume that it's going to be slightly less structured than a native app just because writing HTML, Javascript, and CSS doesn't force you to assume a certain project structure, unlike iPhone apps that have distinct views, controllers, and the like. Depending on what you want to write, this might be liberating, but can also get tangled very quickly.
As middaparka said, you can also use a mixture of the two systems if you'd like. I mean, I'm assuming you're just as good a web developer as you are an iOS developer. If you are stronger in one suit than the other, then I say that you should lean towards heading in that direction. I'd much rather see an excellently written web app than a badly written native app, and vice versa.
I suspect the major advantages/disadvantages relate to the user experience - a "native" UIKit based user interface will feel a lot more natural than manipulating items within a web view. (It'll also mean you can use more "standard" components like navigation controllers, tab bars, etc.)
That said, there's no reason not to use a mix of the two, with the main UI being implemented via the various UIKit objects and the content being provided via a web view.
I would also add that the biggest issue I've found with hybrid frameworks is that you add another dependency to your app.
For example, take a big iOS update. If your chosen framework breaks, your app breaks and you won't be able to fix it until the framework is fixed.
Also, right now there are many frameworks and you have to pray that the one you chose isn't flushed down the toilet or drops support for one of your target platforms.
Another issue is that in a web based app/component you are missing out on platform specific technologies and frameworks like core data, GCD (or any other threading model - which in web you might have do with e.g. Ajax),uitableview with caching etc.
Should you hit a wall when it comes to performance or storage,then you have many more options in the native framework.
How easy it's to come up with a drag and drop web-based interface that'll provide me features to wire objects together, setup configurations nicely in a modal window for each object? I'm looking for links that've any similar kind of interface, or articles on this. also, i'm looking for your technology/language suggestions.
Another way I'm thinking - as a desktop appln + browser dependent addon..
Is it good to create such an user-interface using XUL, which can be deployed as an addon on Firefox/as a stand-alone application in Windows? Are there any other similar things/technologies which can provide a basic framework for us to build on it further?
Why do I need this, finally?
..for building simple Workflows, for defining process flows, that can provide me some auto-generated xml content which I can use for further processing.
Thanks!
I'm quite interested in this, too.
I've flirted with HTML5's DragDrop implementation - Quirksmode has Bad Things to say about that, so then I thought "Perhaps a JavaScript library can help me" - haven't checked out jquery for this yet, but I have checked out YUI's DragDrop, DragDropManager and DataSource, and its looking hopeful (consistent, reliable).
I tried things like adding an iframe on the fly to any document, to provide this kind of functionality without needing to add dependencies to the page given the iframe - mixed results, but in my case I was trying to cater for x-domain access, which proved difficult.
So I'd say JavaScript could be a winner - if designed poorly it could be difficult to manage resources though, if you want to potentially DragDrop/edit/config any element in a document - so watch out for that.
If you're keen and able, Adobe AIR apps also look promising - but I can't help with any more info on that, other than they're Desktop Apps with great flexibility.
I'ma going to keep an eye on your Question, I look forward to any other Answers/comments!
EDIT: I forgot to mention Flex (aka Flash Builder 4, latest version) is quite easy to create stuff like this, though I've had exposure to Flash for a while. It comes with the standard Adobe caveats; price, libraries, support.