I know I have already harangued on this topic, but I feel a need to revisit this at this time. I should probably simply accept Andy's advice and make some non-portal, non-tab layouts, but it seems to defeat the purpose of FM Go, at least on the iPad. I initially accepted TSGal's explanation that the slowness, blocky screen redraw, and overall poor performance of FM Go is some type of effect of the huge processing overhead which multitouch gesturing places upon the iPad's meager computing resources (?), but I finally broke down and purchased a touch tablet computer from a competitor running Windows 7, and while the multitouch interface for that computer stinks, the performance of a standard version of FileMaker Pro is downright snappy. The computer was less than half the price of an iPad, has a full operating system with access to the entire file system, prints to standard printers, and FileMaker Pro was actually FAST. It is in no way as cool as an iPad, as smooth to use, or fun to touch, but it JUST WORKS. What is wrong with that? I expect that if someone replies to this I will be instructed to list this as a feature request, but what do I say? One line summary: "FASTER" What will this feature request accomplish? "FASTER" What is the objective of this feature request (s)? "FASTER" There isn't really very much else to tell. I don't want to insult anyone's intelligence; FM Go just really runs slow. Why is this? Who knows? It looks as if it is running emulated, as if someone ported the app, not the code, directly over, and made some type of wrapper to get it to run on the iPad. That in itself would be pretty impressive, and may give us some insight into what Flash might perform like.
I didn't think it would be appropriate to place this rant into a feature suggestion, but I had to express my surprise. It seems more cost-effective to run a full version of FM Pro on a Windows touch tablet than to run the less expensive but slow version of FM Go on the ultra cool iPad. How disappointing.
Can someone at least explain for me why FMGo handles screen redraw the way that it does (even on a local file)? Has anyone tried using FM Go for iPhone on the iPad? Is it any faster?
Prior to using FM GO for the iPad, we had our verticle app running on a SamsungQ100 thing... I did a little bit of layout tailoring to make the fonts just right for readability, I made the buttons larger for fingers but basically kept the front end intact from what I had designed for a PC/Mac client. It worked, but not ideally well.
As soon as Go was released we immediately moved it to the FM GO for iPad... and the app worked but as JS posted it was not usable. It was slower, but some layout objects as I posted above were problematic. We redesigned the layouts again and optimized for the iPad, but due to the way we designed, the client portals could not be easily replaced. It worked though, and I agree with JS it did not work as well as the Windows based FMP full client. IOW not good enough.
Fast forward a few months to 1 month ago. I finally get the time to go back again to this app and this time users are begging for an iPhone/iPod optimization. This time I do not simply redesign the layouts. This time I redeign the user interface. Not the entire apps UI, only that aspect of the app which will be used during handheld operations. I use list views rather then portals, I split the operations which were all on one layout into a sequence of layouts navigated to and from by on screen buttons. I design to the device. The result was a MAJOR breakthru for this app. The productivity of the app, the usefullness of the app was multiplied 10 fold. It runs as fast as the user needs it to... read that as no waiting. There was another incredible benefit as well.... the reason for the need had to do with the very big drop in cost for an 8G ipod touch Vs the price of a Windows tablet. Using 1 copy of FMP (nonAdvanced) with my file (which now operates on all of the devices described above) in peer to peer sharing a company using my app needs only 1 PC or Mac and as many as 9 ipod touches. The cost is astoundingly LOW!!!
Bottomline... do it right for the device and it will be best IMO!!!
BTW we talk about the above in detail over many months on our podcast "Filemaker Success Tips".
One of the topics we talked about include using FMGo for the Iphone/Ipod on the iPad (rather then FM Go for the iPad). Yes it is much more snappy, but there's less to process anyways by virue of a layout made for a smaller screen. My bet is a design for the Touch running on an ipod FMG will be the same.
Thanks for the advice, Andy,
I will try to implement some of this; the difficulty is that some of my layouts have multiple portals on them. It makes some information input and retrieval easier to manage. My complaint is not ONLY because I'm lazy; I won't deny that, otherwise I wouldn't be using a computer. I just wish someone could explain to me why the iPad can run all of these slick, crazy, 3-D graphics and video, but something which should be essentially the display of text (I tried this using just text fields and a native tab interface) seems to crawl like it's emulated or running on a machine a world away, even for files that are hosted directly on the iPad (basic, no-frills, five fields, no graphics, a tab interface, and a couple of portals, one file, ten or so records). The iPod Touch does sound like a really cost-effective option, but I actually bought an iPad on the basis of the promise of being able to run a full FileMaker database.