It should work on the phones without creating a seperate app. After all,
that's the whole point of putting actual browsers on the phones (iPhone is
running the desktop version of Safari with some multitouch enhancements).
Have you tried running it under desktop Safari? Also, try upgrading to 1.5
or 1.6 (1.5 should have less chance of breaking things but 1.6 has
performance & stability improvements I believe).
Have you performed the steps I recommended for tracking down the cause using
the server-side code?
Also, different browsers do have different behaviours, so if you've never
tested your app on Safari on the desktop, I would seriously recommend
starting there as it uses a completely different rendering engine (Webkit
which is also what Android uses).
On Tue, Apr 14, 2009 at 4:13 AM, Lothar Kimmeringer <j...@kimmeringer.de>wrote:
>
> Hello all,
>
> Arthur Kalmenson schrieb:
>
> > As Vitali mentioned, you want to make sure you're not holding onto any
> > pointers for widgets you don't need. This will prevent the garbage
> > collector from freeing up that memory. On the desktop that's usually
> > fine, but on mobile apps you really need to keep an eye out for that.
>
> At the moment I'm already doing that. The application is organized
> that way, that I have a tree on the left side, that creates a widget
> in dependence of the entry being clicked (using the code I posted
> before), so until somebody clicked on something, I can be sure
> that there is no reference in the system to a particular widget.
>
> Before I place the newly created widget I remove the widget that
> has been placed before using the following code:
>
> IMainPanel panel = (IMainPanel) horizontalSplitPanel.getRightWidget();
> if (panel != null){
> panel.shutdown();
> horizontalSplitPanel.remove((Widget) panel);
> }
>
> Should I call panel.removeFromParent() explicitly in addition to
> calling remove or is this happening automatically in
> horizontalSplitPanel?
>
> > Is your mobile app the same as the desktop version or are there
> > dedicated mobile views?
>
> There is no mobile version of that application and the application
> is simply too big and complex to do that. It's not too much of a
> problem because there was no initial plan to target this application
> for mobile devices (it's the administrative backend I was speaking
> about already on this list with ca. 1MB of compiled code).
>
> I was just curious in the beginning to see this app running on
> the iPhone and the Android device I currently have my hands on
> and was positively surprised that more or less everything works
> (at least on the iPhone, the Android system even can't login
> using Basic Authentication) until the point the application
> "crashed". So if there are steps I can do to enable this already
> existing application on an iPhone this would be a quite cool
> thing to show e.g. on workshops with customers but it's nothing
> sale-numbers are dependent on it.
>
> > I'd probably suggest to make a separate GWT
> > app for the mobile version, refactor the desktop one to pull out all
> > the common parts, and inherit them in the mobile version .
>
> This would effectively double the amount of work for - in this
> specific case - no win in productivity of our customers. If this
> application works on an iPhone or Android browser it would be nice,
> but it's nothing essential at the moment.
>
>
> Best regards, Lothar
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
