[gatein-dev] Mobile Spec Feedback

[Matt Wringe]

On Tue, 2012-03-06 at 21:11 -0500, Ken Finnigan wrote:
> Matt, 
> 
> I've read through all the Mobile specs you've written for GateIn, and here is my feedback: 

Thanks, yeah, there are a few typos and such in the specs right now,
they are more of a draft to see what others feedback is before making
them more concrete. Thanks for looking over it, comments in line below.

> 
>     • Mobile Detection 
> 
> 
>         • Introduction 
> 
> 
>             • Last paragraph has a typo, think the "m" needs to be a
> comma in "content between devicesm different content" 
>         • 
> Use Cases 
> 
>             • 2nd bullet has an "except" that should be "expect" 
>         • 
> Replaceability 
> 
>             • Agree that we need something smart enough to be able to
> determine whether the filter is active to prevent UI admin display,
> while also providing a way to turn the whole thing off. If there's a
> configuration setting for turning on and off, would it be a case of
> the filter is always active, but just skips over itself if the
> configuration setting is deactivated? This would enable it to be
> reactivated without necessitating a portal restart, I'd imagine. There
> may be a dynamic/fancy way of doing it too 

We shouldn't really use filters anymore. The navigation controller now
controls how portal urls are mapped. I have already updated my prototype
to use a WebRequestHandler instead.

I don't know if it makes sense for it to be completely plugable and
remove all trace of it from the admin ui if its removed (nor have I
started to create the ui components yet). It will be setup so that its
disabled by default and will require either an xml configuration file to
be configured, or enabled through the admin ui.

The logic for determining redirects will be a service, and the admin can
write their own service implementation to handle this if they want to
use a custom solution. The device detection will also be configurable as
well, so the admin can select exactly what they want to check for.

If someone wants to have their own completely different configuration,
they are also free to use their own custom filter or some other
mechanism to handle it. They would just need to make sure the built in
one is disabled.


> Mobile Redirection and Mirroring 
> 
>         • Workflow 
> 
> 
>             • Definitely think that the logic paths to go from
> original url to destination url need to be cached. Maybe add that as
> first step in flow to check cache for existing mapping from orig->dest
> for matching orig. Then updates to mappings by admin could cause flush
> of cache to that part of the tree impacted. ie. admin changing
> mappings for portal/foo/x/y will flush cache for portal/foo/x/y and
> anything lower, but cache for portal/foo/x and other children of x
> still remain 

Yes, caching needs to be done. 

> Mobile Manual Redirection Selection 
> 
>         • I think there should be the option for the user to decide
> whether this alternative site will always be redirected to
> (cookie/session is updated), or only this one occasion (session is
> updated) 

I disagree, we should only give the user the option to always redirect
but make it easy for them to switch back.
 
> Mobile Look and Feel 
> 
>         • Is there a link for the touch based gestures at the end of
> the Introduction yet?

The look and feel is a bit farther away and has other things which need
to be fixed before we get into things like gestures. Gestures are not
going to be supported at least for the first couple of releases of this.
Its more important to get the device detection and redirection working
properly.

>     • 
> Mobile Portlet Development 
> 
>         • Use Cases 
> 
> 
>             • Look and Feel has typo of "fell" instead of "feel" 
>     • 
> General 
> 
>         • Could the Navigation Controller be leveraged to provide any
> of this URL mapping or routing that would be required in switching
> between desktop/tablet/mobile? 

Yes, I am using the navigation controller now and using some internal
services to determine mappings and routings. For now I am concentrating
on just allowing switching between sites on the same portal which makes
things a lot easier. I will have to see later if there is much of a need
to have redirection between separate distinct portals or between other
separate websites (between separate distinct portals becomes a bit
tricky since I don't think we have remote capabilities to detect if a
node exists or not).
> 
> Given the current architecture of the platform, ie. not geared for
> mobile, I believe the specs you've outlined are a great step into the
> portal supporting mobile. Impressed with the various aspects that
> you've covered thoroughly. 
> 
> 
> Ken