2:47 a.m.
Hi,
My idea having a native UI, but all logic in javascript has to have a name so let’s call
it hybrid Cordova.
I experimented a bit yesterday with the idea and it seems very feasible. On the Cordova
home page they have already a guide how to include the Cordova web view on a native
project, with that creating a interface to be able to call javascript is almost to easy.
What I have now is a native (android) button that calls a javascript function. It uses a
plugin to call the javascript and offers a static method for the execution.
So to take this to the next level, I think we need a bit of a javascript api to do page
navigation. And have a bit of a Java Api to initialise the WebView and specify the name of
the script to load. Or just pickup all scripts in a assets directory.
WDYT, is it worth exploring further?
Cheers,
Erik Jan
3:24 a.m.
On 20 Jan 2015, at 09:47, Erik Jan de Wit <edewit(a)redhat.com>
wrote:
Hi,
My idea having a native UI, but all logic in javascript has to have a name so let’s call
it hybrid Cordova.
I experimented a bit yesterday with the idea and it seems very feasible. On the Cordova
home page they have already a guide how to include the Cordova web view on a native
project, with that creating a interface to be able to call javascript is almost to easy.
some links:
http://cordova.apache.org/docs/en/4.0.0/guide_hybrid_webviews_index.md.ht...
an interesting blog post on iOS/Codova embedded webview:
http://devgirl.org/2014/07/22/mixing-cordova-phonegap-components-with-nativ/
What I have now is a native (android) button that calls a javascript
function. It uses a plugin to call the javascript and offers a static method for the
execution.
mind to share a demo repo?
So to take this to the next level, I think we need a bit of a
javascript api to do page navigation. And have a bit of a Java Api to initialise the
WebView and specify the name of the script to load. Or just pickup all scripts in a assets
directory.
WDYT, is it worth exploring further?
yeap, not sure yet what the js api need to look like but this could be useful for a
form-based cordova screen you’d like to integrate with a more complex native apps.
we can deal with navigation and data storage.
to be investigated further.
Cheers,
Erik Jan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:39 a.m.
mind to share a demo repo?
https://github.com/edewit/CordovaCommunication
> So to take this to the next level, I think we need a bit of a javascript api to do
page navigation. And have a bit of a Java Api to initialise the WebView and specify the
name of the script to load. Or just pickup all scripts in a assets directory.
>
> WDYT, is it worth exploring further?
yeap, not sure yet what the js api need to look like but this could be useful for a
form-based cordova screen you’d like to integrate with a more complex native apps.
we can deal with navigation and data storage.
to be investigated further.
Cool thing about this you could still use all cordova plugins, so you could have data
storage as a native still.
3:25 a.m.
Sounds like a good project for a student on the "Google Summer of Code"?
On Tue, Jan 20, 2015 at 9:47 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
My idea having a native UI, but all logic in javascript has to have a name
so let’s call it hybrid Cordova.
I experimented a bit yesterday with the idea and it seems very feasible.
On the Cordova home page they have already a guide how to include the
Cordova web view on a native project, with that creating a interface to be
able to call javascript is almost to easy.
What I have now is a native (android) button that calls a javascript
function. It uses a plugin to call the javascript and offers a static
method for the execution.
So to take this to the next level, I think we need a bit of a javascript
api to do page navigation. And have a bit of a Java Api to initialise the
WebView and specify the name of the script to load. Or just pickup all
scripts in a assets directory.
WDYT, is it worth exploring further?
Cheers,
Erik Jan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11:38 a.m.
On 01/20/2015 04:40 AM, Erik Jan de Wit wrote:
> Sounds like a good project for a student on the "Google
Summer of Code"?
>
Right, or I could do it while I ‘wait’ for iOS and android sync libraries
Or you
could help us with the sync libraries.
Right now passos and I are discussing making APIs to connect with the
sync server and FeedHenry's services. After we figure out what that
will look like from an API/usage standpoint we can begin designing that
code. After that point we will need to figure out how to work it into
the Android Sync Adapter framework (which will probably require some
work on the auth/authz end).
We've got a planning gist right now to define our epics before we make
individual JIRA tasks.
https://gist.github.com/secondsun/68cbbc54366b653f57d6
If you could become a FH sync expert this week it would do amazing
things for our ability to move forward.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>Phone:404 941 4698
>Java is my crack.
11:49 a.m.
On Tue, Jan 20, 2015 at 6:38 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
On 01/20/2015 04:40 AM, Erik Jan de Wit wrote:
>> Sounds like a good project for a student on the "Google Summer of
Code"?
>>
> Right, or I could do it while I ‘wait’ for iOS and android sync libraries
Or you could help us with the sync libraries.
that or anything else, is way higher priority
Right now passos and I are discussing making APIs to connect with the
sync server and FeedHenry's services.
Not sure we should duplicate functionality that's already available inside
of the FH SDK.
My pref. here is focusing on our real-time sync server first..... I don't
get why using the FH SDK for accessing the sync framework from feedhenry is
not good enough
After we figure out what that
will look like from an API/usage standpoint we can begin designing that
code. After that point we will need to figure out how to work it into
the Android Sync Adapter framework (which will probably require some
work on the auth/authz end).
We've got a planning gist right now to define our epics before we make
individual JIRA tasks.
https://gist.github.com/secondsun/68cbbc54366b653f57d6
If you could become a FH sync expert this week it would do amazing
things for our ability to move forward.
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11:54 a.m.
On 01/20/2015 12:49 PM, Matthias Wessendorf wrote:
On Tue, Jan 20, 2015 at 6:38 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
On 01/20/2015 04:40 AM, Erik Jan de Wit wrote:
>> Sounds like a good project for a student on the "Google Summer
of Code"?
>>
> Right, or I could do it while I ‘wait’ for iOS and android sync
libraries
Or you could help us with the sync libraries.
that or anything else, is way higher priority
Right now passos and I are discussing making APIs to connect with the
sync server and FeedHenry's services.
Not sure we should duplicate functionality that's already available
inside of the FH SDK.
My pref. here is focusing on our real-time sync server first..... I
don't get why using the FH SDK for accessing the sync framework from
feedhenry is not good enough
It may be enough. I don't have enough information
to make this claim
however. At the very least there will need to be shim code to make sure
it plays nicely with the other Aerogear things. For instance we may
want to use a Keycloak OAuth solution to retrieve tokens to talk to
FH.sync. We will need to have enough support in AG.sync to pass those
tokens to FH.sync.
Also the FH Android SDK is very incomplete right now and is missing
features that are in the FH JS SDK and in AG Android. They will need to
be written at some point by someone.
After we figure out what that
will look like from an API/usage standpoint we can begin designing
that
code. After that point we will need to figure out how to work it into
the Android Sync Adapter framework (which will probably require some
work on the auth/authz end).
We've got a planning gist right now to define our epics before we make
individual JIRA tasks.
https://gist.github.com/secondsun/68cbbc54366b653f57d6
If you could become a FH sync expert this week it would do amazing
things for our ability to move forward.
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>Phone:404 941 4698
>Java is my crack.
12:02 p.m.
On Tue, Jan 20, 2015 at 6:54 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
On 01/20/2015 12:49 PM, Matthias Wessendorf wrote:
On Tue, Jan 20, 2015 at 6:38 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
> On 01/20/2015 04:40 AM, Erik Jan de Wit wrote:
> >> Sounds like a good project for a student on the "Google Summer of
> Code"?
> >>
> > Right, or I could do it while I ‘wait’ for iOS and android sync
> libraries
> Or you could help us with the sync libraries.
>
that or anything else, is way higher priority
>
> Right now passos and I are discussing making APIs to connect with the
> sync server and FeedHenry's services.
Not sure we should duplicate functionality that's already available
inside of the FH SDK.
My pref. here is focusing on our real-time sync server first..... I
don't get why using the FH SDK for accessing the sync framework from
feedhenry is not good enough
It may be enough. I don't have enough information to make this claim
however. At the very least there will need to be shim code to make sure it
plays nicely with the other Aerogear things. For instance we may want to
use a Keycloak OAuth solution to retrieve tokens to talk to FH.sync. We
will need to have enough support in AG.sync to pass those tokens to FH.sync.
Again, my preference here is to limit our current sync work on the
real-time stuff. We can do the FH 'adapter' always at a later time (e.g.
this summer or fall)
-Matthias
Also the FH Android SDK is very incomplete right now and is missing
features that are in the FH JS SDK and in AG Android. They will need to be
written at some point by someone.
> After we figure out what that
> will look like from an API/usage standpoint we can begin designing that
> code. After that point we will need to figure out how to work it into
> the Android Sync Adapter framework (which will probably require some
> work on the auth/authz end).
>
> We've got a planning gist right now to define our epics before we make
> individual JIRA tasks.
>
> https://gist.github.com/secondsun/68cbbc54366b653f57d6
>
> If you could become a FH sync expert this week it would do amazing
> things for our ability to move forward.
>
>
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12:50 p.m.
On 20 Jan,2015, at 18:49 , Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Jan 20, 2015 at 6:38 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/20/2015 04:40 AM, Erik Jan de Wit wrote:
>> Sounds like a good project for a student on the "Google Summer of
Code"?
>>
> Right, or I could do it while I ‘wait’ for iOS and android sync libraries
Or you could help us with the sync libraries.
that or anything else, is way higher priority
don’t have other ideas atm
3414
days inactive
3414
days old
9 comments
4 participants
participants (4)
-
Corinne Krych -
Erik Jan de Wit -
Matthias Wessendorf -
Summers Pittman