Mobile vs desktop app

Question

After having gained some familiarity with the jQuery Mobile framework (which is fantastic), it appears as if we would need to maintain 2 versions of the Apex application, one optimized for a desktop browser and another for a mobile device. A homepage would redirect to the appropriate version depending on the device accessing it using some modern detection library like Modernizr
But looking at other technologies like ASP.NET that implement the MVC framework, it looks like there is a way to cleanly separate content from the presentation layer. This is something Apex is unable to do because component templates cannot be changed at run-time.
Maintaining 2 versions of the same Apex application is not something that I am looking forward to. Surely there is some clever way to have your cake and eat it too.
Any ideas? Am I missing something? Thanks

Answer 1

Hello Vikas,
>> I am not sure I concur with your assessment above since presentation in Apex is determined by templates which are fixed for a given application
Presentation is indeed determined by templates, however, template parsing is performed per page request (for simplicity sake I’m ignoring APEX cache). I’m pretty sure you are using conditioned regions. Conditioned regions actually mean that the logic of the page can determine the way it will be rendered. Let’s go back for a moment to the translation mechanism. APEX 4.0 introduced the p_lang parameter, as part of the f?p URL. This parameter instructs the APEX engine in which language to render the first page, before any session state actions has been taken. We can use a similar parameter, e.g. p_media, which will set a built-in substitution string, e.g. APP_MEDIA, that you’ll be able to use to condition your page regions. As a single page can include various regions, each with its own template, you’ll be able to control which region will be the one to displayed – optimized for desktop or optimized to mobile.
The point I’m trying to make is that when APEX saves your logic – report SQL queries, list of items, etc. – it doesn’t saves with it the way these elements are displayed. This information is kept separately. You can easily change the entire application theme without any logic changes; you can transform a classic report to IR, etc.
>> short of designing to the lowest common denominator (mobile), I still don't see how it is possible to have ONE Apex application that would look different on a mobile vs desktop device, see the points in my earlier post.
I believe that we all agree that in some cases you need to design your page differently, according to the target media it’s going to use. For example, I have an application that includes a phonebook. Each phone record has about 30 possible information items. When invoked from a desktop, all the fields are displayed (including, for example, the empty ones). When invoked from a mobile platform, only about, or up to, 8 fields, which contain data, are displayed (BTW, one can claim that this is a pure logic issue and not only presentation issue, as you need to determine which fields are going to be displayed). Anyway, I’m having a single application which includes different pages for different medias. At the time, my options were not as wide as the ones we have with 4.1, and remember that we are only at the beginning of the road.
>> Thanks for your example on apex.oracle.com but I know that Apex allows 100% control over the templates used to render content and 4.1 has some improvements in this area but I am not sure it is germane to this discussion
The point I was trying to make is that even with the current 4.1 version, which doesn’t include official mobile support, the APEX engine is already equipped with (almost) everything we need to generate HTML code that is compatible with JQM demands, and that we can do it on a single page.
>> [On a related note - When Form Items in Table is set to No, I am guessing table-based item layout attributes like Begin on New Line, Rowspan/Colspan would be ignored. So how would item layout in the region be controlled? Using pure CSS techniques like float, clear, etc? I am not a CSS expert, I guess I can't see how the region template and label template interact to produce the desired layout]
You are correct. When Form Items in Table is set to No all the declarative layout fields are void. I updated my demo page to show an example of a region – the second one - where we are using a DIV based layout without any CSS. The third region shows an example of the same region, this time with the use of a very minimal CSS.
DIV based layout is neither declarative nor simple, at least for now. It requires a lot of CSS code, and not in the basic level. Compared with the current table based layout options, which are highly declarative, and can give you quite complex layouts (sub- regions, etc.) we have a very long way to go with the DIV based layout. However, you need to remember that in the mobile arena, layout demand tends to be much simpler.
>> Case in point - Report region since that is the primary component used to display content … even if you build a 100% DIV-based report and region template, I don't know if JQM can use DIVs exclusively to format content. As per the JQM docs, it needs the UL element to provide some semantic meaning to the markup.
You keep getting back to the UL element, and I’m not sure why. I agree that when you need to format lists, this is an important element (which APEX also uses), however, JQM also supports grid layout, which based on DIVs - http://jquerymobile.com/demos/1.0b2/#/demos/1.0b2/docs/content/content-grids.html. I believe this can be used with reports.
As Marc confirmed in one of his threads, much of the ways APEX will support mobile applications will be determined by the JQM technologies and options. For now, and I believe mainly to allow future (relative easy) backward compatibility, the current 4.1 version of the APEX engine includes options to accommodate the most obvious JQM demand. As we all know, the development team is very open to new ideas and suggestions (as the new 4.1 translation mechanism clearly shows) so we can hope that they will consider all options to make our life as developers simpler and easier. I’m sure they are aware, just like us, of the growing trend of mobile development. I’m sure they will devote a lot of thinking to the subject. I never spoke with Joel about that (as you know, Oracle doesn’t publish its future plans and strategies, and I have to respect that), but my impression is that where APEX is concerned, the only thing carved in stone is the use of JQM. Everything else is open.
Regards,
Arie.
♦ Please remember to mark appropriate posts as correct/helpful. For the long run, it will benefit us all.
♦ Author of Oracle Application Express 3.2 – The Essentials and More