asynchttp without render, redirect and callback's WebView

[laerg]

'lo all,

I'm developing for android with :

djeezus@dy:~/$ gem list | grep rhodes

rhodes (3.5.1.12)

I'm using asynchttp.[post|get] for a lot of data loading and refreshing 

Why do I need to render, WebView.navigate, execute_js or at best "refresh" at all ?

Why can't I just leave that out, and leave the current view as is ?

My refresh_methods doing asynchttp are triggered with RhoTimer, and I have to do a WebView.refresh there too, it makes the UI reload (flash on, flash off) wherever it is at that point.

it makes no sense

Maybe there is a best practice for this ?  maybe a wait page, but I'd rather not, it's too annoying and hardly necessary ...

In antoher context, I also tried working with the Alert.show_popup and Alert.hide_popup, but it seems they run asynchronously too, and you'd need to be clairvoyant to know when to hide a popup

otherwise you get an unresponsive UI.  Same question applies here, how could they be put to good use at all ?  Or maybe I'm just missing the point :) 

grtz,

gert

[Jon Tara]

Why do I need to render, WebView.navigate, execute_js or at best "refresh" at all ?

You don't.

Why can't I just leave that out, and leave the current view as is ?

You can.

In Rhodes 2.x, you need to use *some* controller with AsyncHttp, because the only way to receive callbacks is through a controller method. I usually borrow Settings for that. Your controller method doesn't have to call render, redirect, etc. Just handle the response (store it, process it, whatever) and return.

In Rhodes 4.x, you can now send callbacks to a lambda, so you don't need a controller.

I never use wait pages - they are a bad idea.

[Djeezus]

'lo Jon,

glad to see you're still hanging around ... my first app ever I used your iScrollView ; anyway ...

Why do I need to render, WebView.navigate, execute_js or at best "refresh" at all ?

You don't.

I thought it always rendered by default a view ? if none was specified, it looked for an .erb with same name as controller def, no ? 

Why can't I just leave that out, and leave the current view as is ?

You can.

Well yes, but if I do, I always get some ugly transition or page flashes (or whatever they're called) and/or an "undefined" error if a view is missing :(  I don't want any transition at all, and obviously no error either :)

View :

index.erb

... parse @profiles.each do |profile| in listview ...

Controller :

def index

 @profiles = Profiles.find(:all, ....)

...

end

def blah1

asynchttp ... callback url_for :action => blah1_callback

# norender/noWebView ...

end

def blah1_callback

 parse reply ...

 webview.navigate url_for :action => blah2 (why can't I just redirect :action to next def ... what's so special about a callback, that I have to use a WebView to naviate? )

end

def blah2

asynchttp some more stuff ...

...

end

def blah2_callback

....

WebView.navigate(url_for :action => :index)

end

I do 4 gets/posts like this whenever a user switches profile ( well, not all the time, the Rhom model has a timestamp field, and only does asynchttps if older than n hours ... but you get the idea.)

Whenever these blah1|2|3|... defs are executed the current "index" view flashes/blanks a couple of times ... this is the part I'm referring to ... how to avoid that, and just refresh once when "WebView.navigate(url_for :action => :index)" is called ?

 

In Rhodes 2.x, you need to use *some* controller with AsyncHttp, because the only way to receive callbacks is through a controller method. I usually borrow Settings for that. Your controller method doesn't have to call render, redirect, etc. Just handle the response (store it, process it, whatever) and return.

Any idea when the rhodes4 gem will be available ... maybe i should compile from git, is that 4.x ? 

  

grtz & thnx,

Gert 

[Jon Tara]

If you don't want to render, I don't understand why you have an ERB?

If you have an ERB, and no matching controller method, then it will render the ERB. If you have a matching controller method, don't have  matching ERB, and don't call render, then no rendering is done. Not sure what happens if you have a matching controller method AND an ERB, and don't call render.

Don't try to use the same controller method for two purposes. If you need an index, then have an index controller method and ERB. Don't try to re-use this for some other purpose.

Just create a controller method, say, "do_some_stuff_with_async_http". Don't create a corresponding ERB. Have your UI post to the controller. Don't call render. There should not be any rendering.

[Alexey Tikhvinsky]

Hi Djezus,

I think it will be good idea to move to rhodes 4.0, Then you can use JS API.

Also you can use AJAX requests to ruby controller. In this case you do not need to do render every time.

-alexey

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rhomobile+...@googlegroups.com.
To post to this group, send email to rhom...@googlegroups.com.
Visit this group at http://groups.google.com/group/rhomobile.
For more options, visit https://groups.google.com/groups/opt_out.

[Djeezus]

'lo Alexey, Jon

I get it now, I was struggling (getting frustated actually) with scheduled updates for my local data(rhom fixed scheme) via asynchttp calls to a webservice. I've added now to each callback a condition like this :

 

if "#{@@from}" == "scheduled"

      Rho::Timer.start(120000, 'app/Friends/get_friends', 'from=scheduled')

  else

    WebView.navigate(url_for :action => :index)

  end

Also, not quite sure if I've used the Rho::Timer callback params as intended, but it works for me like this :)

So I tried the git-Rhodes version as you suggested any way, and although it builds my app fine (also with latest ndk btw, which is not supported with 3.5.1.12) it seems that at least the async_http callbacks have changed in syntax, and are not backward compatible ?  So, for now I'm not continuing down this lane I guess.

I have also recently upgraded to jqmobile-1.4, because I'm trying to make the app look as native as possible, and I wanted to play with the new "panel" functions in 1.4, but I'm not sure about the new "pagecontainer" function to change pages via execute_js ... maybe I just don't understand fully :(

WebView.execute_js(" $(':mobile-pagecontainer').pagecontainer('change', '/app/Login/index', 

      {

        transition: 'slide',

        showLoadMsg: true,

        reload: true

      } 

      ); ")

The 'old'  WebView.execute_js("$.mobile.changePage('index');") is stil supported, but "deprecated", so i'd rather not use it any more ... so for now, I've fallen back to WebView.navigate.  What does this actually do in the background to move around in the app ?

grtz,

gert 

--
You received this message because you are subscribed to a topic in the Google Groups "rhomobile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rhomobile/nJDM4xL7io0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rhomobile+...@googlegroups.com.

To post to this group, send email to rhom...@googlegroups.com.
Visit this group at http://groups.google.com/group/rhomobile.
For more options, visit https://groups.google.com/groups/opt_out.

--

iT's aLl jUsT f0r LaUgH5 I teLLz yA !

[Stephen Benner]

The 'old'  WebView.execute_js("$.mobile.changePage('index');") is stil supported, but "deprecated", so i'd rather not use it any more ... so for now, I've fallen back to WebView.navigate.  What does this actually do in the background to move around in the app ?

The execute_js method was intended to supplement navigation with javascript to animate transitions and things. It used the method 'insertAsyncPage' I believe. This is now all depreciated I think. I never found the 'jqmobile-patch.js' containing all of this very useful - in fact I don't even use it in my app and things work just fine. Most of the code is redundant. It's a pretty messy operation to be honest. Don't worry about using execute_js - it wasn't anything special in the first place :)

WebView is the API to the lower-level C implementation of the WebView object, so it directly accesses the native iOS object and is responsible for controlling the internal server. WebView receives requests to the server that come from URLs such as those put into anchors with 'url_for'. It then serves all the pages of your app when you navigate to another URL. JQM is pretty hard to learn; I struggled with the concepts for a long time. Basically what happens when you load a new page via URL navigation such as clicking on an anchor, is that JQM pre-loads the data into the DOM, and then you can have a nice transition, because JQM handles the animation. On the other hand when you call WebView.navigate directly, you are changing the content of your browser - it's loading a new page and JQM can't keep track of where you were or where you're going, so there is no page in the DOM most of the time, and no reliable animated transitions. WebView.navigate bypasses JQM navigation, and this is a pretty big limitation.

[Stephen Benner]

Oh and I should mention that the Rhodes 4 API is poorly documented, just like it's predecessor... For instance in the docs for Rho::Network.get(), the return object is described as having fields 'body', 'headers', 'cookies', and 'http_error', but if something goes wrong with the request, then the return object is inconsistent; I have received one with fields '

'body', 'error_code', 'status', and 'headers'. Pretty irksome to deal with.

[Egghead]

Was AsyncHTTP better? BTW, is Network.get and Network.post supported in RMS 2?