Hussey, You absolutely weren't rambling! Comments really useful and appreciated.
I think jqm looks the way forward, probably with separate desktop version (will push IT guy a bit on this to confirm). RE: MVC, I hear what you say but maybe we do fall into the complicated category where it could be required. Initial map will be where anyone can report / upload photos of live wildlife e sightings from map (on mobile, tablet, laptop etc) to Fusion Tables will then display markers according to type of sighting, age etc. And that to work on any device. So a bit tricky, but I think the MVC piece will be most useful because we want to develop multiple versions of a similar thing (for different national parks, companies and also for different purposes such as reporting potholes etc etc.). Plus some plans to move to apps later on. So have something modular - which is my understanding of the MVC approach - will simplify things in long term. My IT guy has also recommended a 'web service' to save the data to and fetch from the Fusion Table etc. I'm not quite sure what this means and whether necessary. Worried about being taken down a proprietary, bespoke route that would tie myself to one developer etc. Always much prefer to stick to standard / Google APIs where possible. Don't know if you have any thoughts on the necessity of such a service given description of map above? Anyway - thanks so much for comments. I feel at least partially "armed" now. Rob On Feb 16, 5:32 pm, hussey <[email protected]> wrote: > I'm working on a mobile version of my site right now, and am very > happy with my decision to use jquery mobile. > > For simpler sites you may find that jquery mobile, if designed > appropriately from the start, will suffice even for desktop users. If > you notice their demo (which is the same as their docs) expands > beautifully on desktop browsers. I assume this just uses different CSS > style sheets and good planning with their "pages" as they call them. > Extra effort in those areas might be better than maintaining different > code for desktop vs mobile. > > That said, there are very real issues with map usage on desktop vs > mobile. The way you click and move the map around uses different > events and if you have a complicated desktop map with custom > interactive functions you might feel better writing separate versions > just to keep your sanity, and the size down. BTW, jqm has nice > "virtual" events used to normalize event handling, so you don't have > to write separate bindings for mobile touches vs mouse clicks etc... > > I'm guessing that it was your IT consultant that talked about moving > to a MVC framework. Of course that and OO are best practices, but I'm > not sure if that really applies to your situation as much the > consultant probably made it sound. Map complexity would mostly be > handled by the maps api and a couple of their add-ons, which is pretty > well streamlined in that regard. Are you in need of customizing beyond > typical maps api usage? Your back-end technologies will most likely be > the same for all devices, including the database to store your > location data and even the formulas for calculating what to display, > etc.. So keeping everything separate (MVC) will be helpful if you > ever want to move to a different technology (different map provider, > different database, make an app instead of a website maybe) but > probably not too relevant for the issues you're facing now (different > devices, complicated maps). I guess I might be rambling at this point > so I'll stop here. > > On Feb 16, 1:55 am, Rob Maclean <[email protected]> wrote: > > > > > > > > > Hello, > > > We have various versions of web apps that use Maps V3 API and Fusion > > Tables to enable users to submit their own content to a map using a > > simple form, and that content appears immediately on a live map for > > others to see. It currently works OK on a PC but we're encountering > > issues on some other platforms (e.g. iPhone / iPad to submit photos). > > Going forward the primary usage will be on mobile and we need to come > > up with a solution that is simple, modular, 'future-proofed' and will > > able to be incorporated in apps (android and apple). > > > Here is a prototype example of one > > application:www.satpacktravel.com/kruger-sightings.html. > > > I've done some research and would really appreciate any / all thoughts > > on the following. Some of this is copied from a recommendation from an > > IT consultant, so would appreciate responses in as non-technical terms > > as possible: > > > 1. Moving to a MVC framework and use of OOPS(Class/Objects structure) > > concepts. This seems to be the best way to manage complex maps with > > multiple versions of similar functionality? > > 2. Move to have two different version of each map, i.e. map identifies > > devices and then utilises 1 of 2 different codes. Is type of devices > > (e.g. phone / tablet or PC or is screen size the best criteria)? > > 3. We currently use JQuery. Happy to keep this for PC version. On > > mobile version looking at JQuery Mobile vs. Snecha Touch. > > Documentation and similarity with JQuery seems better with former? Any > > advantages of Snecha? > > > Thank you for any and all help! > > > Rob -- You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.
