On Wed, Apr 8, 2009 at 9:54 AM, Lothar Kimmeringer <j...@kimmeringer.de>wrote:
>
> Vitali Lovich schrieb:
> >
> > Android:
> > - The browser coming with G1 is not able to do
> > HTTP Basic Authentication (WTF?)
> >
> > That seems strange & unlikely given that it's Chrome (or at least some
> > kind of Webkit-based browser). Try running your app in Chrome on the
> > desktop - does that work? Do you have the latest updates on the phone?
>
> I don't have Chrome on the desktop (I don't agree with the terms of
> usage, so I'm not able to install it).
Would installing it in a temporary VM be ok? Then you can just wipe the VM
afterwards.
The phone was updated about
> one month ago. The phone's message is quite clear:
> "Das Authentifizierungsschema fuer die Site wird nicht unterstuetzt."
> (The site's authentication-scheme is not supported)
>
> The server's response-header looks OK to me:
>
> $ telnet 127.0.0.1 9000
> Trying 127.0.0.1...
> Connected to 127.0.0.1.
> Escape character is '^]'.
> GET / HTTP/1.0
> Host: localhost
>
> HTTP/1.1 401 Unauthorized
> Date: Wed, 08 Apr 2009 13:44:31 GMT
> Server: IS/5.7.20_14442
> WWW-Authenticate: basic realm="HUB Admin Realm"
> Content-Type: text/html
> Content-Length: 1127
> Connection: close
I don't have much experience with the HTTP auth route - I tend to do the
authentication through the GWT RPC approach.
>
>
> > Mobile Safari:
> > - Safari on an iPod touch 2G is showing the application after
> > some while and crashes after doing some RPC-calls.
> > - Safari on an iPhone 2G shows the application but instead
> > of crashing, the browser fails to do RPC-calls after a while.
> >
> > Do you see these problems on the desktop version of Safari?
>
> No, the application is running smoothly there.
Are you sure that the RPC calls stop & that your app isn't crashing? Try
this in your onModuleLoad:
new Timer() {
public void run() {
rpcServiceAsync.doRpcHeartbeat(System.currentTimeMillis(), new
AsyncCallback<Void>() {public void onFailure(Throwable cause){} public void
onSuccess(Void result){}});
}
}.scheduleRepeating(5000);
where doRpcHeartbeat is an RPC invocation where you just log the timestamp
on the server or something. That way you can be sure that you can tell if
suddenly RPC stops working (by the way, there's a limit to how many
concurrent outstanding AJAX calls you can make - could you be hitting this
limit?).
>
>
> > The iPhone
> > & desktop versions are pretty much identical in the backend. What do
> > you mean by crashes?
>
> When working with the application it suddenly vanishes in the same
> way it do when you press the "Main"-button. I never saw this behavior
> on other pages, so I assume that it's killed by the operating system
> because there is not enough memory and Safari wasn't able to free
> up enough ressources after being told so by the system (which lead
> to the kill of the application).
Are your phones jailbroken? If so, there might be some performance monitors
you can run (at the very least you have top) to get a sense of why Safari
crashes (does Apple provide developer tools for determining why Safari
unloads the page?)
>
>
> So "crashing" might not be the correct term here but the user-
> experience is the same ;-)
>
> [Splitting GWT-application to reduce memory-consumption]
>
> > Build from trunk & use GWT.runAsync
> > <http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting>.
>
> Looks good (meaning that I still can skip 1.5 and can go from
> 1.4.60 to 1.6 directly).
Not 1.6 - must be trunk. Code splitting wasn't put into 1.6. It's one of
the major featres that's going into 2.0 with OOPHM being another one.
>
>
> Two questions that I don't find answered in the page you linked:
>
> 1. My application is already modularized, every page allowing
> the administration of one particular "service" is a class
> derived from a superclass "AbstractServicePanel". When clicking
> on an entry in the list of services, a method is called that
> is evaluating the panel to be initialized:
>
> AbstractServicePanel panel = null;
> try{
> if (status.handlingName.equals("AS2Service")){
> panel = new As2ServicePanel();
> }
> else if (status.handlingName.equals("LogService")){
> panel = new LogServicePanel();
> }
> else if (status.handlingName.equals("authplain")){
> panel = new AuthServicePanel();
> }
> else if (status.handlingName.equals("commlogplain")){
> panel = new CommunicationLogServicePanel();
> }
> [etc]
> else if (status.handlingName.equals("AdminService")){
> panel = new AdminServicePanel();
> }
> }
> catch(Throwable t){
> callback.onFailure(t);
> return;
> }
> if (panel == null){
> panel = new UnimplementedPanel(status);
> }
> callback.onSuccess(panel);
>
> The callback removes a previously shown panel and adds the new
> one. Is it enough to put the whole if-cascade into one GWT.runAsync
> or do I have to do it for every if-statement if I want to let GWT
> perform a deferred loading for each panel?
Depends what you want to do. From my understanding, surrounding the whole
thing will mean that all those classes will be brought in at once, whereas
doing it per panel will mean that it brings in each panel as necessary.
However, you have to be careful because you have to rework your logic (your
loads all of a sudden become asynchronous).
There's also the additional problem that you don't really want to do it for
all of them. Ideally, you would use the SOYC tool to get a sense of how big
each portion is & see if it's worth it to split it out. Also, just
surrounding your code with the runAsync is insufficient - you need to make
sure that there's no other code that references the split code, otherwise
it'll be brought in with the rest of the application. The SOYC tool should
help here too.
>
>
> 2. Is it possible to "unload" loaded parts? Otherwise I might be
> able to run the application in the beginning but the longer the
> application is used (i.e. the more panels are loaded and initialized),
> the higher the likelyhood of running out of ressources will be.
No - this concept is not supported in browsers from what I'm aware. But the
issue has never been code size in the sense of browser memory usage (code
splitting is really for improving start-up performance for applications by
transferring the initial code that is absolutely necessary & transferring
the rest in the background). It's always the DOM structure that gets
generated by your code that would be the culprint behind any memory issues.
>
>
> > You may also want to ensure
> > that you aren't leaving cycles in your references, thereby preventing
> > garbage collection (i.e. when you remove a widget, remove it's listeners
> > as well).
>
> Is there a link to the GWT-documentation where this problem is
> explained further? If I have a Panel, containing a button and
> I add a ClickListener to that Button, do I really have to remove
> that ClickListenner from the Button before removing the Panel?
I never did find this information. From what I've understood with
discussions from the GWT developers is that GWT is very careful about
avoiding these situations so you don't need to manually do this. I could
very well be wrong about this (and it does seem like you would have to do it
manually cause you can remove the panel, then add it back & you would expect
it to have all the same listeners). One way would be through inversion of
control pattern - have a class that adds the listeners you want to the
widgets you care about, but also add it to a static Map<Widget,
List<Listener>>.
You may also want to check out http://www.josh-davis.org/node/5 - not GWT
specific (might not even apply), but a good read for understanding GC issues
with browsers.
>
>
> > Since you're also dealing with the mobile space, you may want
> > to make sure that when you hide a composite, you actually remove it from
> > the page & then recreate it as necessary if it gets added back (unless
> > it's really expensive).
>
> I've got quite complex Dialog-boxes. How can I remove a Dialog-box?
> At the moment I'm only calling hide().
removeFromParent() actually detaches the panel from the DOM. Calling
clear() on a Panel will remove all child widgets.
>
>
>
> Thanks and 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
-~----------~----~----~----~------~----~------~--~---
