This content has been marked as final. Show 9 replies
you could use a before header branch on the first page (page 1?) after login to directly redirect to different "start pages".
If you could somehow pass some variable from the login page, containing the browser info, there could be two different branches with PL/SQL conditions like you described in your post.
Edit: This might be helpful to get the browser info:
Re: How to prevent old-browser user from login
Hope this helps somehow...
Edited by: sakra on 07.01.2013 04:50
Thx for your suggestion but "page processing" is just some of the things that might differ in desktop/mobile run time (I have some loging, changing behaviour of some items, and many other things that I'd might have in future).
So I'd like to get something that is implemented in Apex core (default Apex app url-without page, just app_id in url, knows how to redirect to desktop/mobile page).
So I'd like to understand how is that working.
I think there must be something ... "PL/SQL-able" to get that information.
According mine previous post I'm looking for something like (suppose that "OWA_UTIL" is that package ... jsut suppose I do not say this is true):
l_device_info:=OWA_UTIL.get_device_info;This will help me a lot to implement mine logic in many places (whenever it is possible to differ mobile/desktop( screening or process approach.
IF l_device_info='desktop' THEN
ELSIF l_device_info='mobile' THEN
Hope now is more clear.
Edited by: Damir Vadas on Jan 7, 2013 5:52 AM
as soon as APEX has detected the user interface and redirected you to the related login page, you can use the package apex_page to determine the user interface of the current page. It has the following APIs.
Is that what you are looking for?
--============================================================================== -- Returns TRUE if the current page has been designed for Desktop browsers. --============================================================================== function is_desktop_ui return boolean; -- --============================================================================== -- Returns TRUE if the current page has been designed for smartphone devices -- using jQuery Mobile. --============================================================================== function is_jqm_smartphone_ui return boolean; -- --============================================================================== -- Returns TRUE if the current page has been designed for tablet devices -- using jQuery Mobile. --============================================================================== function is_jqm_tablet_ui return boolean; -- --============================================================================== -- Returns the UI type for which the current page has been designed for. --============================================================================== function get_ui_type return varchar2;
My Blog: http://www.inside-oracle-apex.com
APEX Plug-Ins: http://apex.oracle.com/plugins
Thank you very much for this info. This is very progressive point. I think I could do manage many things with your answer.
But frankly Id like to get more detail about your part:
*... as soon as APEX has detected the user interface*
How really Apex detect that? Where is this part implemented if not too hidden?
If this code might be reviewed that will be a gold for me ... and I think many Apex developer.
Rg and all the best in 2013.
that code is embedded in the part of the engine which sets up the session at the beginning of request processing. It basically examines the USER_AGENT http header to detect the user interface. I can not show you the Apex source code, but there are other frameworks in various languages (some of them open source, e.g. Categorizr) that do similar things:
Our device detection code runs when the URL does not contain a page id. It loops over all user interfaces that are installed in the app and redirects to the home page of that one which can be automatically detected. If there is an ambiguity, Apex renders a built-in device selection page. We also thought about client-side detection and the hooks are in place (wwv_flow_ui_types.autodetect_js_function_body). That is not yet implemented, though.