From wtrocki at redhat.com Tue Aug 15 12:50:55 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Tue, 15 Aug 2017 13:50:55 +0100 Subject: [feedhenry-dev] RainCatcher project update Message-ID: See: https://www.redhat.com/archives/feedhenry-raincatcher/2017-August/msg00000.html WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Tue Aug 15 13:26:55 2017 From: dpassos at redhat.com (Daniel Passos) Date: Tue, 15 Aug 2017 10:26:55 -0300 Subject: [feedhenry-dev] Normalize Feedhenry repo names Message-ID: Hi All, I was chatting with Wojtek Trocki this morning about sync and I have suggested to the new repos following the same pattern we have on AeroGear ## For libraries: feedhenry-[platform]-[feature]-[languege] ### Examples: feedhenry-android-sync-java feedhenry-android-sync-kotlin feedhenry-ios-sync-objc feedhenry-ios-sync-swift feedhenry-cordova-sync ## For example/cookbook/apps/templates feedhenry-[platform]-[feature]-[language]-app ### Examples feedhenry-android-sync-java-app feedhenry-android-sync-kotlin-app feedhenry-ios-sync-objc-app feedhenry-ios-sync-swift-app feedhenry-cordova-sync-app I know maybe FeedHenry in the start of the repo name can be a little redundant on the GitHub but not on your machine when you have a lot of projects and it also will also prevent to have the same name of other libraries ;) -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmadigan at redhat.com Tue Aug 15 14:38:27 2017 From: jmadigan at redhat.com (Jason Madigan) Date: Tue, 15 Aug 2017 15:38:27 +0100 Subject: [feedhenry-dev] Normalize Feedhenry repo names In-Reply-To: References: Message-ID: Sounds like a good suggestion to me. And with GH, there's basically 0-cost to renaming repos with redirects in place, so would get a +1 from me. On Tue, Aug 15, 2017 at 2:26 PM, Daniel Passos wrote: > Hi All, > > I was chatting with Wojtek Trocki this morning about sync and I have > suggested to the new repos following the same pattern we have on AeroGear > > ## For libraries: > > feedhenry-[platform]-[feature]-[languege] > > ### Examples: > > feedhenry-android-sync-java > feedhenry-android-sync-kotlin > feedhenry-ios-sync-objc > feedhenry-ios-sync-swift > feedhenry-cordova-sync > > ## For example/cookbook/apps/templates > > feedhenry-[platform]-[feature]-[language]-app > > ### Examples > > feedhenry-android-sync-java-app > feedhenry-android-sync-kotlin-app > feedhenry-ios-sync-objc-app > feedhenry-ios-sync-swift-app > feedhenry-cordova-sync-app > > I know maybe FeedHenry in the start of the repo name can be a little > redundant on the GitHub but not on your machine when you have a lot of > projects and it also will also prevent to have the same name of other > libraries ;) > > -- > -- Passos > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Jason Madigan Engineering Manager, Red Hat Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Tue Aug 15 14:45:26 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Tue, 15 Aug 2017 15:45:26 +0100 Subject: [feedhenry-dev] Normalize Feedhenry repo names In-Reply-To: References: Message-ID: I do not mind any name changes until we will be consistent. Currently we have: https://github.com/feedhenry/fh-sync https://github.com/feedhenry/fh-sync-js New repository: https://github.com/feedhenry/fh-sync-android We have two options 1) Name android and ios using `fh` prefix (fh-sync-android, fh-sync-ios) 2) Rename all to `feedhenry-..` First option seems better to me. Regards WOJCIECH TROCKI Red Hat Mobile IM: wtrocki On Tue, Aug 15, 2017 at 3:38 PM, Jason Madigan wrote: > Sounds like a good suggestion to me. And with GH, there's basically 0-cost > to renaming repos with redirects in place, so would get a +1 from me. > > On Tue, Aug 15, 2017 at 2:26 PM, Daniel Passos wrote: > >> Hi All, >> >> I was chatting with Wojtek Trocki this morning about sync and I have >> suggested to the new repos following the same pattern we have on AeroGear >> >> ## For libraries: >> >> feedhenry-[platform]-[feature]-[languege] >> >> ### Examples: >> >> feedhenry-android-sync-java >> feedhenry-android-sync-kotlin >> feedhenry-ios-sync-objc >> feedhenry-ios-sync-swift >> feedhenry-cordova-sync >> >> ## For example/cookbook/apps/templates >> >> feedhenry-[platform]-[feature]-[language]-app >> >> ### Examples >> >> feedhenry-android-sync-java-app >> feedhenry-android-sync-kotlin-app >> feedhenry-ios-sync-objc-app >> feedhenry-ios-sync-swift-app >> feedhenry-cordova-sync-app >> >> I know maybe FeedHenry in the start of the repo name can be a little >> redundant on the GitHub but not on your machine when you have a lot of >> projects and it also will also prevent to have the same name of other >> libraries ;) >> >> -- >> -- Passos >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Jason Madigan > Engineering Manager, Red Hat Mobile > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Tue Aug 15 15:25:46 2017 From: dpassos at redhat.com (Daniel Passos) Date: Tue, 15 Aug 2017 12:25:46 -0300 Subject: [feedhenry-dev] Normalize Feedhenry repo names In-Reply-To: References: Message-ID: I have no problem to use fh- instead of feedhenry, just wanna have a whatever FeedHenry prefix. What I really wanna have is the repo using a pattern fh-[platform]-[feature]-[language] Like: fh-js-sync fh-android-sync-java fh-ios-sync-objc fh-ios-swift-objc Maybe we can use fh-js-sync-server or whatever you like for the server repo Wdyt? On Tue, Aug 15, 2017 at 11:45 AM, Wojciech Trocki wrote: > I do not mind any name changes until we will be consistent. > Currently we have: > > https://github.com/feedhenry/fh-sync > https://github.com/feedhenry/fh-sync-js > > New repository: > https://github.com/feedhenry/fh-sync-android > > We have two options > 1) Name android and ios using `fh` prefix (fh-sync-android, fh-sync-ios) > 2) Rename all to `feedhenry-..` > > First option seems better to me. > > Regards > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > On Tue, Aug 15, 2017 at 3:38 PM, Jason Madigan > wrote: > >> Sounds like a good suggestion to me. And with GH, there's basically >> 0-cost to renaming repos with redirects in place, so would get a +1 from me. >> >> On Tue, Aug 15, 2017 at 2:26 PM, Daniel Passos >> wrote: >> >>> Hi All, >>> >>> I was chatting with Wojtek Trocki this morning about sync and I have >>> suggested to the new repos following the same pattern we have on AeroGear >>> >>> ## For libraries: >>> >>> feedhenry-[platform]-[feature]-[languege] >>> >>> ### Examples: >>> >>> feedhenry-android-sync-java >>> feedhenry-android-sync-kotlin >>> feedhenry-ios-sync-objc >>> feedhenry-ios-sync-swift >>> feedhenry-cordova-sync >>> >>> ## For example/cookbook/apps/templates >>> >>> feedhenry-[platform]-[feature]-[language]-app >>> >>> ### Examples >>> >>> feedhenry-android-sync-java-app >>> feedhenry-android-sync-kotlin-app >>> feedhenry-ios-sync-objc-app >>> feedhenry-ios-sync-swift-app >>> feedhenry-cordova-sync-app >>> >>> I know maybe FeedHenry in the start of the repo name can be a little >>> redundant on the GitHub but not on your machine when you have a lot of >>> projects and it also will also prevent to have the same name of other >>> libraries ;) >>> >>> -- >>> -- Passos >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> Jason Madigan >> Engineering Manager, Red Hat Mobile >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Tue Aug 15 15:37:26 2017 From: jfrizell at redhat.com (John Frizelle) Date: Tue, 15 Aug 2017 16:37:26 +0100 Subject: [feedhenry-dev] Normalize Feedhenry repo names In-Reply-To: References: Message-ID: Generally in favour of this. 2 questions: 1. Do we need both platform and language? fh-*android*-sync-*java* What about JavaScript and Xamarin fh-js-sync-js ? fh-cordova-sync-js ? fh-xamarin-sync-dotnet ? 2. Should the feature come before the platform - e.g. fh-android-sync fh-ios-sync vs fh-sync-android fh-sync-ios I *think* it should be platform first so that everything related to android / ios / cordova is grouped, but wanted to ask the question... -- John Frizelle Chief Architect, Red Hat Mobile Consulting Engineer mobile: *+353 87 290 1644 * twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell at redhat.com * On 15 August 2017 at 16:25, Daniel Passos wrote: > I have no problem to use fh- instead of feedhenry, just wanna have a > whatever FeedHenry prefix. What I really wanna have is the repo using a > pattern fh-[platform]-[feature]-[language] > > Like: > > fh-js-sync > fh-android-sync-java > fh-ios-sync-objc > fh-ios-swift-objc > > Maybe we can use fh-js-sync-server or whatever you like for the server repo > > Wdyt? > > > On Tue, Aug 15, 2017 at 11:45 AM, Wojciech Trocki > wrote: > >> I do not mind any name changes until we will be consistent. >> Currently we have: >> >> https://github.com/feedhenry/fh-sync >> https://github.com/feedhenry/fh-sync-js >> >> New repository: >> https://github.com/feedhenry/fh-sync-android >> >> We have two options >> 1) Name android and ios using `fh` prefix (fh-sync-android, fh-sync-ios) >> 2) Rename all to `feedhenry-..` >> >> First option seems better to me. >> >> Regards >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> >> On Tue, Aug 15, 2017 at 3:38 PM, Jason Madigan >> wrote: >> >>> Sounds like a good suggestion to me. And with GH, there's basically >>> 0-cost to renaming repos with redirects in place, so would get a +1 from me. >>> >>> On Tue, Aug 15, 2017 at 2:26 PM, Daniel Passos >>> wrote: >>> >>>> Hi All, >>>> >>>> I was chatting with Wojtek Trocki this morning about sync and I have >>>> suggested to the new repos following the same pattern we have on AeroGear >>>> >>>> ## For libraries: >>>> >>>> feedhenry-[platform]-[feature]-[languege] >>>> >>>> ### Examples: >>>> >>>> feedhenry-android-sync-java >>>> feedhenry-android-sync-kotlin >>>> feedhenry-ios-sync-objc >>>> feedhenry-ios-sync-swift >>>> feedhenry-cordova-sync >>>> >>>> ## For example/cookbook/apps/templates >>>> >>>> feedhenry-[platform]-[feature]-[language]-app >>>> >>>> ### Examples >>>> >>>> feedhenry-android-sync-java-app >>>> feedhenry-android-sync-kotlin-app >>>> feedhenry-ios-sync-objc-app >>>> feedhenry-ios-sync-swift-app >>>> feedhenry-cordova-sync-app >>>> >>>> I know maybe FeedHenry in the start of the repo name can be a little >>>> redundant on the GitHub but not on your machine when you have a lot of >>>> projects and it also will also prevent to have the same name of other >>>> libraries ;) >>>> >>>> -- >>>> -- Passos >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> Jason Madigan >>> Engineering Manager, Red Hat Mobile >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> > > > -- > -- Passos > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From wtrocki at redhat.com Tue Aug 15 15:44:00 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Tue, 15 Aug 2017 16:44:00 +0100 Subject: [feedhenry-dev] Normalize Feedhenry repo names In-Reply-To: References: Message-ID: > What I really wanna have is the repo using a pattern fh-[platform]-[feature]-[language] In our case we talking about 'project' instead of feature so format fh-[project]-[language/platform] seems to be better suited (at least I see this being adapted in other os projects) Once we detach project it can possibly live their own life (it can be even renamed). > Maybe we can use fh-js-sync-server or whatever you like for the server repo That's really hard to decode. Sync server is just... fh-sync WOJCIECH TROCKI Red Hat Mobile IM: wtrocki On Tue, Aug 15, 2017 at 4:25 PM, Daniel Passos wrote: > I have no problem to use fh- instead of feedhenry, just wanna have a > whatever FeedHenry prefix. What I really wanna have is the repo using a > pattern fh-[platform]-[feature]-[language] > > Like: > > fh-js-sync > fh-android-sync-java > fh-ios-sync-objc > fh-ios-swift-objc > > Maybe we can use fh-js-sync-server or whatever you like for the server repo > > Wdyt? > > > On Tue, Aug 15, 2017 at 11:45 AM, Wojciech Trocki > wrote: > >> I do not mind any name changes until we will be consistent. >> Currently we have: >> >> https://github.com/feedhenry/fh-sync >> https://github.com/feedhenry/fh-sync-js >> >> New repository: >> https://github.com/feedhenry/fh-sync-android >> >> We have two options >> 1) Name android and ios using `fh` prefix (fh-sync-android, fh-sync-ios) >> 2) Rename all to `feedhenry-..` >> >> First option seems better to me. >> >> Regards >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> >> On Tue, Aug 15, 2017 at 3:38 PM, Jason Madigan >> wrote: >> >>> Sounds like a good suggestion to me. And with GH, there's basically >>> 0-cost to renaming repos with redirects in place, so would get a +1 from me. >>> >>> On Tue, Aug 15, 2017 at 2:26 PM, Daniel Passos >>> wrote: >>> >>>> Hi All, >>>> >>>> I was chatting with Wojtek Trocki this morning about sync and I have >>>> suggested to the new repos following the same pattern we have on AeroGear >>>> >>>> ## For libraries: >>>> >>>> feedhenry-[platform]-[feature]-[languege] >>>> >>>> ### Examples: >>>> >>>> feedhenry-android-sync-java >>>> feedhenry-android-sync-kotlin >>>> feedhenry-ios-sync-objc >>>> feedhenry-ios-sync-swift >>>> feedhenry-cordova-sync >>>> >>>> ## For example/cookbook/apps/templates >>>> >>>> feedhenry-[platform]-[feature]-[language]-app >>>> >>>> ### Examples >>>> >>>> feedhenry-android-sync-java-app >>>> feedhenry-android-sync-kotlin-app >>>> feedhenry-ios-sync-objc-app >>>> feedhenry-ios-sync-swift-app >>>> feedhenry-cordova-sync-app >>>> >>>> I know maybe FeedHenry in the start of the repo name can be a little >>>> redundant on the GitHub but not on your machine when you have a lot of >>>> projects and it also will also prevent to have the same name of other >>>> libraries ;) >>>> >>>> -- >>>> -- Passos >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> Jason Madigan >>> Engineering Manager, Red Hat Mobile >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> > > > -- > -- Passos > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Tue Aug 15 16:26:00 2017 From: supittma at redhat.com (Summers Pittman) Date: Tue, 15 Aug 2017 12:26:00 -0400 Subject: [feedhenry-dev] Normalize Feedhenry repo names In-Reply-To: References: Message-ID: On Tue, Aug 15, 2017 at 11:37 AM, John Frizelle wrote: > Generally in favour of this. > > 2 questions: > 1. Do we need both platform and language? > fh-*android*-sync-*java* > What about JavaScript and Xamarin > fh-js-sync-js ? > fh-cordova-sync-js ? > fh-xamarin-sync-dotnet ? > I think that we need language where it is relevant. In the case of Xamarin and Windows the .Net is (often) redundant. In Android the java until VERY recently was redundant, but isn't any more. I think I can spin it around a little. If I see "fh-js-sync" then I expect it to work anywhere a javascript interpreter is. So this means I can embed it in Rhino, .Net, Electron, React Native, or Cordova. Likewise with "fh-dotNet-sync" I think it should work in Mono, Xamarin, Windows, etc. But these flow from the expectation that the platform is the second selector. Does that make sense? > > 2. Should the feature come before the platform - e.g. > fh-android-sync > fh-ios-sync > vs > fh-sync-android > fh-sync-ios > > I *think* it should be platform first so that everything related to > android / ios / cordova is grouped, but wanted to ask the question... > > The answer is do we expect people to look for android on feedhenry or sync on feedhenry when they are browsing github. > > > > -- > John Frizelle > Chief Architect, Red Hat Mobile > Consulting Engineer > > mobile: *+353 87 290 1644 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 15 August 2017 at 16:25, Daniel Passos wrote: > >> I have no problem to use fh- instead of feedhenry, just wanna have a >> whatever FeedHenry prefix. What I really wanna have is the repo using a >> pattern fh-[platform]-[feature]-[language] >> >> Like: >> >> fh-js-sync >> fh-android-sync-java >> fh-ios-sync-objc >> fh-ios-swift-objc >> >> Maybe we can use fh-js-sync-server or whatever you like for the server >> repo >> >> Wdyt? >> >> >> On Tue, Aug 15, 2017 at 11:45 AM, Wojciech Trocki >> wrote: >> >>> I do not mind any name changes until we will be consistent. >>> Currently we have: >>> >>> https://github.com/feedhenry/fh-sync >>> https://github.com/feedhenry/fh-sync-js >>> >>> New repository: >>> https://github.com/feedhenry/fh-sync-android >>> >>> We have two options >>> 1) Name android and ios using `fh` prefix (fh-sync-android, fh-sync-ios) >>> 2) Rename all to `feedhenry-..` >>> >>> First option seems better to me. >>> >>> Regards >>> >>> WOJCIECH TROCKI >>> >>> Red Hat Mobile >>> >>> IM: wtrocki >>> >>> >>> On Tue, Aug 15, 2017 at 3:38 PM, Jason Madigan >>> wrote: >>> >>>> Sounds like a good suggestion to me. And with GH, there's basically >>>> 0-cost to renaming repos with redirects in place, so would get a +1 from me. >>>> >>>> On Tue, Aug 15, 2017 at 2:26 PM, Daniel Passos >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> I was chatting with Wojtek Trocki this morning about sync and I have >>>>> suggested to the new repos following the same pattern we have on AeroGear >>>>> >>>>> ## For libraries: >>>>> >>>>> feedhenry-[platform]-[feature]-[languege] >>>>> >>>>> ### Examples: >>>>> >>>>> feedhenry-android-sync-java >>>>> feedhenry-android-sync-kotlin >>>>> feedhenry-ios-sync-objc >>>>> feedhenry-ios-sync-swift >>>>> feedhenry-cordova-sync >>>>> >>>>> ## For example/cookbook/apps/templates >>>>> >>>>> feedhenry-[platform]-[feature]-[language]-app >>>>> >>>>> ### Examples >>>>> >>>>> feedhenry-android-sync-java-app >>>>> feedhenry-android-sync-kotlin-app >>>>> feedhenry-ios-sync-objc-app >>>>> feedhenry-ios-sync-swift-app >>>>> feedhenry-cordova-sync-app >>>>> >>>>> I know maybe FeedHenry in the start of the repo name can be a little >>>>> redundant on the GitHub but not on your machine when you have a lot of >>>>> projects and it also will also prevent to have the same name of other >>>>> libraries ;) >>>>> >>>>> -- >>>>> -- Passos >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Jason Madigan >>>> Engineering Manager, Red Hat Mobile >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >> >> >> -- >> -- Passos >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From supittma at redhat.com Tue Aug 15 16:34:01 2017 From: supittma at redhat.com (Summers Pittman) Date: Tue, 15 Aug 2017 12:34:01 -0400 Subject: [feedhenry-dev] FH-Sync and Android O Message-ID: So fh-android-sdk uses a polling thread with a one second timeout to perform sync operations. While the application is in the foreground this is fine since this thread just checks the Sync configuration and makes HTTP calls to sync if a sync timeout has been reached. Because we want a real-ish time experience our demos keep this timeout rather low. Prior to Android O when the application is in the background these aggressive sync timeouts keep the local data updated until the application is killed by the system. After Android O those requests fail and will begin to call the failure callback while the application is backgrounded.* The way that Google advises apps to work around this is to use the JobScheduler APIs. JobScheduler has one downside though, you can't schedule background tasks to run as frequently as the sync APIs want to run. I believe the minimum is once every 15 minutes. For polling from the background this probably isn't a big deal especially if there is a way to return the app to a more aggressive state when it is in the foreground. For the next sprint the client SDK team is looking at implementing JobScheduler for sync because this will make the sync APIs work better in Android O. Does anyone have any objection/points of discussion or clarification to the behavior and restrictions I mentioned? Thanks, Summers * Specifically if the phone has gone into Doze mode. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Tue Aug 15 16:56:36 2017 From: weil at redhat.com (Wei Li) Date: Tue, 15 Aug 2017 17:56:36 +0100 Subject: [feedhenry-dev] FH-Sync and Android O In-Reply-To: References: Message-ID: I don't think it's necessary to run sync with high frequency when it's in the background mode. The app is not being used by the user, so no one cares if the data is actually up to date in the background. >From this point of view, I think it's ok to use the JobScheduler when it's in background. It probably will use less battery as well (I think perhaps we can reduce the frequency of sync when it's running in the background for old Android versions too?). However users do expect the data is up to date ASAP when the app is in foreground mode. So this change is made, we probably should explain how developers can still achieve relatively good UX when the app is in the foreground again. We can either: * make sure sync API is called automatically when the app is brought into foreground. Or, * provide documents & code sample of how to invoke the sync API when the app is in foreground mode. My 2 cents... Thanks, On Tue, Aug 15, 2017 at 5:34 PM, Summers Pittman wrote: > So fh-android-sdk uses a polling thread with a one second timeout to > perform sync operations. While the application is in the foreground this > is fine since this thread just checks the Sync configuration and makes HTTP > calls to sync if a sync timeout has been reached. Because we want a > real-ish time experience our demos keep this timeout rather low. > > Prior to Android O when the application is in the background these > aggressive sync timeouts keep the local data updated until the application > is killed by the system. After Android O those requests fail and will > begin to call the failure callback while the application is backgrounded.* > The way that Google advises apps to work around this is to use the > JobScheduler APIs. > > JobScheduler has one downside though, you can't schedule background tasks > to run as frequently as the sync APIs want to run. I believe the minimum > is once every 15 minutes. For polling from the background this probably > isn't a big deal especially if there is a way to return the app to a more > aggressive state when it is in the foreground. > > For the next sprint the client SDK team is looking at implementing > JobScheduler for sync because this will make the sync APIs work better in > Android O. Does anyone have any objection/points of discussion or > clarification to the behavior and restrictions I mentioned? > > Thanks, > > Summers > > * Specifically if the phone has gone into Doze mode. > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Tue Aug 15 19:55:04 2017 From: weil at redhat.com (Wei Li) Date: Tue, 15 Aug 2017 20:55:04 +0100 Subject: [feedhenry-dev] FH-Sync and Android O In-Reply-To: References: Message-ID: Yeah, agreed. Another thing we can also try is to call the sync API just before the app going into background. That should make sure the local data is uploaded even if the background sync frequency is very low. On Tue, Aug 15, 2017 at 8:44 PM, David Martin wrote: > I think there might be an expectation from some users that ic they use the > app to update some data, that data will be make its way to the server as > soon as possible. > If I make a change in an app then immediately put the app in the > background, I would expect that change to be saved on the server pretty > soon as long as I'm online. It wouldn't seem right if that change I made > only got saved the next time I opened the App. > > To take an hypothetical example, if I use a particular app for logging > work, and log something last thing on a Friday . I then lock my phone, > which puts the App into the background. > The weekend staff take over on Saturday and pick up where I left off. > However, my changes never got synced so they end up repeating some work I > did. > Having some background sync, even if it was every 15 minutes ,could help > prevent this situation . > > On Tue, 15 Aug 2017 17:58 Wei Li, wrote: > >> I don't think it's necessary to run sync with high frequency when it's in >> the background mode. The app is not being used by the user, so no one cares >> if the data is actually up to date in the background. >> From this point of view, I think it's ok to use the JobScheduler when >> it's in background. It probably will use less battery as well (I think >> perhaps we can reduce the frequency of sync when it's running in the >> background for old Android versions too?). >> >> However users do expect the data is up to date ASAP when the app is in >> foreground mode. So this change is made, we probably should explain how >> developers can still achieve relatively good UX when the app is in the >> foreground again. >> We can either: >> * make sure sync API is called automatically when the app is brought into >> foreground. Or, >> * provide documents & code sample of how to invoke the sync API when the >> app is in foreground mode. >> >> My 2 cents... >> >> Thanks, >> >> On Tue, Aug 15, 2017 at 5:34 PM, Summers Pittman >> wrote: >> >>> So fh-android-sdk uses a polling thread with a one second timeout to >>> perform sync operations. While the application is in the foreground this >>> is fine since this thread just checks the Sync configuration and makes HTTP >>> calls to sync if a sync timeout has been reached. Because we want a >>> real-ish time experience our demos keep this timeout rather low. >>> >>> Prior to Android O when the application is in the background these >>> aggressive sync timeouts keep the local data updated until the application >>> is killed by the system. After Android O those requests fail and will >>> begin to call the failure callback while the application is backgrounded.* >>> The way that Google advises apps to work around this is to use the >>> JobScheduler APIs. >>> >>> JobScheduler has one downside though, you can't schedule background >>> tasks to run as frequently as the sync APIs want to run. I believe the >>> minimum is once every 15 minutes. For polling from the background this >>> probably isn't a big deal especially if there is a way to return the app to >>> a more aggressive state when it is in the foreground. >>> >>> For the next sprint the client SDK team is looking at implementing >>> JobScheduler for sync because this will make the sync APIs work better in >>> Android O. Does anyone have any objection/points of discussion or >>> clarification to the behavior and restrictions I mentioned? >>> >>> Thanks, >>> >>> Summers >>> >>> * Specifically if the phone has gone into Doze mode. >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> >> WEI LI >> >> SENIOR SOFTWARE ENGINEER >> >> Red Hat Mobile >> >> weil at redhat.com M: +353862393272 >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From acarmona at redhat.com Tue Aug 15 20:19:31 2017 From: acarmona at redhat.com (Andrea Carmona) Date: 15 Aug 2017 16:19:31 -0400 Subject: [feedhenry-dev] Upcoming Red Hat DevNation Live Tech Talk: Sidecars and Microservices Mesh Message-ID: If you have trouble viewing this email, read the online version . "Red Hat" Hi RedHat Join the Red Hat DevNation for an upcoming live session on August 17, 2017, as Christian Posta presents on Sidecars and Microservices Mesh. Description: The first generation of microservices was primarily shaped by NetflixOSS and leveraged by numerous Spring Cloud annotations all throughout your business logic. The next generation of microservices will leverage sidecars and a service mesh. In this session, we will give you a taste of Envoy and Istio, two open source projects that will change the way you write distributed, cloud native, Java applications on Kubernetes. Register Now For more information and to view the schedule, click here . We hope you join us! Regards, Andrea Carmona The Red Hat Developer Program __________________________________________________________________ [f1]Contact our sales team [f2]Manage your newsletter preferences [f3]Read our privacy policy [f4]Unsubscribe from all Red Hat email "Red Hat" and the "Shadowman" logo are trademarks or registered trademarks of Red Hat, Inc. Linux is a registered trademark of Linus Torvalds. ? 2016 Red Hat, Inc. All rights reserved. 100 East Davie Street Raleigh, NC 27601 [f5][twitter.png] [f6][facebook.png] [f7][redhat.png] References f1. http://www.redhat.com/apps/webform.html?event_type=contact_sales&eid=21 f2. https://www.redhat.com/wapps/ugc/email-subscriptions.html?elqc=241&elq=e637309c94dc4410a123582a0a32ae3c f3. http://www.redhat.com/legal/privacy_statement.html f4. https://www.redhat.com/wapps/ugc/master-unsubscribe.html?elqc=241&elq=e637309c94dc4410a123582a0a32ae3c f5. http://www.twitter.com/redhatnews f6. http://www.facebook.com/pages/Red-Hat/11218770329 f7. http://www.redhat.com/community/?sc_cid=70160000000I9TnAAK -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Wed Aug 16 08:48:21 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Wed, 16 Aug 2017 09:48:21 +0100 Subject: [feedhenry-dev] FH-Sync and Android O In-Reply-To: References: Message-ID: Just to provide context. JavaScript version has no background operations - sync is happening only when on foreground. When changes are made (add) sync loop is triggered automatically. This may be considered as workaround for problem mentioned above. Having service and waking up application to make request will have huge impact on app battery usage. Best to find some tradeoff between battery life and update times. WOJCIECH TROCKI Red Hat Mobile IM: wtrocki On Tue, Aug 15, 2017 at 8:55 PM, Wei Li wrote: > Yeah, agreed. Another thing we can also try is to call the sync API just > before the app going into background. That should make sure the local data > is uploaded even if the background sync frequency is very low. > > On Tue, Aug 15, 2017 at 8:44 PM, David Martin wrote: > >> I think there might be an expectation from some users that ic they use >> the app to update some data, that data will be make its way to the server >> as soon as possible. >> If I make a change in an app then immediately put the app in the >> background, I would expect that change to be saved on the server pretty >> soon as long as I'm online. It wouldn't seem right if that change I made >> only got saved the next time I opened the App. >> >> To take an hypothetical example, if I use a particular app for logging >> work, and log something last thing on a Friday . I then lock my phone, >> which puts the App into the background. >> The weekend staff take over on Saturday and pick up where I left off. >> However, my changes never got synced so they end up repeating some work I >> did. >> Having some background sync, even if it was every 15 minutes ,could help >> prevent this situation . >> >> On Tue, 15 Aug 2017 17:58 Wei Li, wrote: >> >>> I don't think it's necessary to run sync with high frequency when it's >>> in the background mode. The app is not being used by the user, so no one >>> cares if the data is actually up to date in the background. >>> From this point of view, I think it's ok to use the JobScheduler when >>> it's in background. It probably will use less battery as well (I think >>> perhaps we can reduce the frequency of sync when it's running in the >>> background for old Android versions too?). >>> >>> However users do expect the data is up to date ASAP when the app is in >>> foreground mode. So this change is made, we probably should explain how >>> developers can still achieve relatively good UX when the app is in the >>> foreground again. >>> We can either: >>> * make sure sync API is called automatically when the app is brought >>> into foreground. Or, >>> * provide documents & code sample of how to invoke the sync API when the >>> app is in foreground mode. >>> >>> My 2 cents... >>> >>> Thanks, >>> >>> On Tue, Aug 15, 2017 at 5:34 PM, Summers Pittman >>> wrote: >>> >>>> So fh-android-sdk uses a polling thread with a one second timeout to >>>> perform sync operations. While the application is in the foreground this >>>> is fine since this thread just checks the Sync configuration and makes HTTP >>>> calls to sync if a sync timeout has been reached. Because we want a >>>> real-ish time experience our demos keep this timeout rather low. >>>> >>>> Prior to Android O when the application is in the background these >>>> aggressive sync timeouts keep the local data updated until the application >>>> is killed by the system. After Android O those requests fail and will >>>> begin to call the failure callback while the application is backgrounded.* >>>> The way that Google advises apps to work around this is to use the >>>> JobScheduler APIs. >>>> >>>> JobScheduler has one downside though, you can't schedule background >>>> tasks to run as frequently as the sync APIs want to run. I believe the >>>> minimum is once every 15 minutes. For polling from the background this >>>> probably isn't a big deal especially if there is a way to return the app to >>>> a more aggressive state when it is in the foreground. >>>> >>>> For the next sprint the client SDK team is looking at implementing >>>> JobScheduler for sync because this will make the sync APIs work better in >>>> Android O. Does anyone have any objection/points of discussion or >>>> clarification to the behavior and restrictions I mentioned? >>>> >>>> Thanks, >>>> >>>> Summers >>>> >>>> * Specifically if the phone has gone into Doze mode. >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> >>> WEI LI >>> >>> SENIOR SOFTWARE ENGINEER >>> >>> Red Hat Mobile >>> >>> weil at redhat.com M: +353862393272 >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Tue Aug 15 19:44:48 2017 From: davmarti at redhat.com (David Martin) Date: Tue, 15 Aug 2017 19:44:48 +0000 Subject: [feedhenry-dev] FH-Sync and Android O In-Reply-To: References: Message-ID: I think there might be an expectation from some users that ic they use the app to update some data, that data will be make its way to the server as soon as possible. If I make a change in an app then immediately put the app in the background, I would expect that change to be saved on the server pretty soon as long as I'm online. It wouldn't seem right if that change I made only got saved the next time I opened the App. To take an hypothetical example, if I use a particular app for logging work, and log something last thing on a Friday . I then lock my phone, which puts the App into the background. The weekend staff take over on Saturday and pick up where I left off. However, my changes never got synced so they end up repeating some work I did. Having some background sync, even if it was every 15 minutes ,could help prevent this situation . On Tue, 15 Aug 2017 17:58 Wei Li, wrote: > I don't think it's necessary to run sync with high frequency when it's in > the background mode. The app is not being used by the user, so no one cares > if the data is actually up to date in the background. > From this point of view, I think it's ok to use the JobScheduler when it's > in background. It probably will use less battery as well (I think perhaps > we can reduce the frequency of sync when it's running in the background for > old Android versions too?). > > However users do expect the data is up to date ASAP when the app is in > foreground mode. So this change is made, we probably should explain how > developers can still achieve relatively good UX when the app is in the > foreground again. > We can either: > * make sure sync API is called automatically when the app is brought into > foreground. Or, > * provide documents & code sample of how to invoke the sync API when the > app is in foreground mode. > > My 2 cents... > > Thanks, > > On Tue, Aug 15, 2017 at 5:34 PM, Summers Pittman > wrote: > >> So fh-android-sdk uses a polling thread with a one second timeout to >> perform sync operations. While the application is in the foreground this >> is fine since this thread just checks the Sync configuration and makes HTTP >> calls to sync if a sync timeout has been reached. Because we want a >> real-ish time experience our demos keep this timeout rather low. >> >> Prior to Android O when the application is in the background these >> aggressive sync timeouts keep the local data updated until the application >> is killed by the system. After Android O those requests fail and will >> begin to call the failure callback while the application is backgrounded.* >> The way that Google advises apps to work around this is to use the >> JobScheduler APIs. >> >> JobScheduler has one downside though, you can't schedule background tasks >> to run as frequently as the sync APIs want to run. I believe the minimum >> is once every 15 minutes. For polling from the background this probably >> isn't a big deal especially if there is a way to return the app to a more >> aggressive state when it is in the foreground. >> >> For the next sprint the client SDK team is looking at implementing >> JobScheduler for sync because this will make the sync APIs work better in >> Android O. Does anyone have any objection/points of discussion or >> clarification to the behavior and restrictions I mentioned? >> >> Thanks, >> >> Summers >> >> * Specifically if the phone has gone into Doze mode. >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Wed Aug 16 12:16:13 2017 From: supittma at redhat.com (Summers Pittman) Date: Wed, 16 Aug 2017 08:16:13 -0400 Subject: [feedhenry-dev] FH-Sync and Android O In-Reply-To: References: Message-ID: On Tue, Aug 15, 2017 at 3:55 PM, Wei Li wrote: > Yeah, agreed. Another thing we can also try is to call the sync API just > before the app going into background. That should make sure the local data > is uploaded even if the background sync frequency is very low. > Point of order, during onPause and onStop you are supposed to be releasing resources and ending network connections, not starting new ones. During backgrounding we should not start a new network request, we should migrate pending requests to a background sync mechanism. (aka JobScheduler) > > On Tue, Aug 15, 2017 at 8:44 PM, David Martin wrote: > >> I think there might be an expectation from some users that ic they use >> the app to update some data, that data will be make its way to the server >> as soon as possible. >> If I make a change in an app then immediately put the app in the >> background, I would expect that change to be saved on the server pretty >> soon as long as I'm online. It wouldn't seem right if that change I made >> only got saved the next time I opened the App. >> >> To take an hypothetical example, if I use a particular app for logging >> work, and log something last thing on a Friday . I then lock my phone, >> which puts the App into the background. >> The weekend staff take over on Saturday and pick up where I left off. >> However, my changes never got synced so they end up repeating some work I >> did. >> Having some background sync, even if it was every 15 minutes ,could help >> prevent this situation . >> >> On Tue, 15 Aug 2017 17:58 Wei Li, wrote: >> >>> I don't think it's necessary to run sync with high frequency when it's >>> in the background mode. The app is not being used by the user, so no one >>> cares if the data is actually up to date in the background. >>> From this point of view, I think it's ok to use the JobScheduler when >>> it's in background. It probably will use less battery as well (I think >>> perhaps we can reduce the frequency of sync when it's running in the >>> background for old Android versions too?). >>> >>> However users do expect the data is up to date ASAP when the app is in >>> foreground mode. So this change is made, we probably should explain how >>> developers can still achieve relatively good UX when the app is in the >>> foreground again. >>> We can either: >>> * make sure sync API is called automatically when the app is brought >>> into foreground. Or, >>> * provide documents & code sample of how to invoke the sync API when the >>> app is in foreground mode. >>> >>> My 2 cents... >>> >>> Thanks, >>> >>> On Tue, Aug 15, 2017 at 5:34 PM, Summers Pittman >>> wrote: >>> >>>> So fh-android-sdk uses a polling thread with a one second timeout to >>>> perform sync operations. While the application is in the foreground this >>>> is fine since this thread just checks the Sync configuration and makes HTTP >>>> calls to sync if a sync timeout has been reached. Because we want a >>>> real-ish time experience our demos keep this timeout rather low. >>>> >>>> Prior to Android O when the application is in the background these >>>> aggressive sync timeouts keep the local data updated until the application >>>> is killed by the system. After Android O those requests fail and will >>>> begin to call the failure callback while the application is backgrounded.* >>>> The way that Google advises apps to work around this is to use the >>>> JobScheduler APIs. >>>> >>>> JobScheduler has one downside though, you can't schedule background >>>> tasks to run as frequently as the sync APIs want to run. I believe the >>>> minimum is once every 15 minutes. For polling from the background this >>>> probably isn't a big deal especially if there is a way to return the app to >>>> a more aggressive state when it is in the foreground. >>>> >>>> For the next sprint the client SDK team is looking at implementing >>>> JobScheduler for sync because this will make the sync APIs work better in >>>> Android O. Does anyone have any objection/points of discussion or >>>> clarification to the behavior and restrictions I mentioned? >>>> >>>> Thanks, >>>> >>>> Summers >>>> >>>> * Specifically if the phone has gone into Doze mode. >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> >>> WEI LI >>> >>> SENIOR SOFTWARE ENGINEER >>> >>> Red Hat Mobile >>> >>> weil at redhat.com M: +353862393272 >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Wed Aug 16 12:19:12 2017 From: supittma at redhat.com (Summers Pittman) Date: Wed, 16 Aug 2017 08:19:12 -0400 Subject: [feedhenry-dev] FH-Sync and Android O In-Reply-To: References: Message-ID: On Tue, Aug 15, 2017 at 3:44 PM, David Martin wrote: > I think there might be an expectation from some users that ic they use the > app to update some data, that data will be make its way to the server as > soon as possible. > If I make a change in an app then immediately put the app in the > background, I would expect that change to be saved on the server pretty > soon as long as I'm online. It wouldn't seem right if that change I made > only got saved the next time I opened the App. > > To take an hypothetical example, if I use a particular app for logging > work, and log something last thing on a Friday . I then lock my phone, > which puts the App into the background. > The weekend staff take over on Saturday and pick up where I left off. > However, my changes never got synced so they end up repeating some work I > did. > Having some background sync, even if it was every 15 minutes ,could help > prevent this situation . > > I understand the example you are trying to put forward, but I think it is flawed. In this case I would argue against using sync to send the data; it should be a more traditional (HTTP PUT or POST) mechanism. Sync is useful for the eventually consistent use case. Data is saved locally but it is sent to the cloud when it is appropriate for the device. To your use case though, currently in Android O we can't background sync and in < Android O we can't guarantee a background sync. With JobScheduler we can and the developer gets a better experience. > On Tue, 15 Aug 2017 17:58 Wei Li, wrote: > >> I don't think it's necessary to run sync with high frequency when it's in >> the background mode. The app is not being used by the user, so no one cares >> if the data is actually up to date in the background. >> From this point of view, I think it's ok to use the JobScheduler when >> it's in background. It probably will use less battery as well (I think >> perhaps we can reduce the frequency of sync when it's running in the >> background for old Android versions too?). >> >> However users do expect the data is up to date ASAP when the app is in >> foreground mode. So this change is made, we probably should explain how >> developers can still achieve relatively good UX when the app is in the >> foreground again. >> We can either: >> * make sure sync API is called automatically when the app is brought into >> foreground. Or, >> * provide documents & code sample of how to invoke the sync API when the >> app is in foreground mode. >> >> My 2 cents... >> >> Thanks, >> >> On Tue, Aug 15, 2017 at 5:34 PM, Summers Pittman >> wrote: >> >>> So fh-android-sdk uses a polling thread with a one second timeout to >>> perform sync operations. While the application is in the foreground this >>> is fine since this thread just checks the Sync configuration and makes HTTP >>> calls to sync if a sync timeout has been reached. Because we want a >>> real-ish time experience our demos keep this timeout rather low. >>> >>> Prior to Android O when the application is in the background these >>> aggressive sync timeouts keep the local data updated until the application >>> is killed by the system. After Android O those requests fail and will >>> begin to call the failure callback while the application is backgrounded.* >>> The way that Google advises apps to work around this is to use the >>> JobScheduler APIs. >>> >>> JobScheduler has one downside though, you can't schedule background >>> tasks to run as frequently as the sync APIs want to run. I believe the >>> minimum is once every 15 minutes. For polling from the background this >>> probably isn't a big deal especially if there is a way to return the app to >>> a more aggressive state when it is in the foreground. >>> >>> For the next sprint the client SDK team is looking at implementing >>> JobScheduler for sync because this will make the sync APIs work better in >>> Android O. Does anyone have any objection/points of discussion or >>> clarification to the behavior and restrictions I mentioned? >>> >>> Thanks, >>> >>> Summers >>> >>> * Specifically if the phone has gone into Doze mode. >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> >> WEI LI >> >> SENIOR SOFTWARE ENGINEER >> >> Red Hat Mobile >> >> weil at redhat.com M: +353862393272 >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Wed Aug 16 12:20:34 2017 From: supittma at redhat.com (Summers Pittman) Date: Wed, 16 Aug 2017 08:20:34 -0400 Subject: [feedhenry-dev] FH-Sync and Android O In-Reply-To: References: Message-ID: On Wed, Aug 16, 2017 at 4:48 AM, Wojciech Trocki wrote: > Just to provide context. JavaScript version has no background operations - > sync is happening only when on foreground. > When changes are made (add) sync loop is triggered automatically. This may > be considered as workaround for problem mentioned above. > > Having service and waking up application to make request will have huge > impact on app battery usage. > Best to find some tradeoff between battery life and update times. > > JobScheduler coordinates with the Android OS to bundle operations so they are more respectful of battery and network conditions. It is the official "here is how you do this" solution of Android ;) Not to be confused with the official sync solution for Android. SyncAdapters are overkill for the most part. > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > On Tue, Aug 15, 2017 at 8:55 PM, Wei Li wrote: > >> Yeah, agreed. Another thing we can also try is to call the sync API just >> before the app going into background. That should make sure the local data >> is uploaded even if the background sync frequency is very low. >> >> On Tue, Aug 15, 2017 at 8:44 PM, David Martin >> wrote: >> >>> I think there might be an expectation from some users that ic they use >>> the app to update some data, that data will be make its way to the server >>> as soon as possible. >>> If I make a change in an app then immediately put the app in the >>> background, I would expect that change to be saved on the server pretty >>> soon as long as I'm online. It wouldn't seem right if that change I made >>> only got saved the next time I opened the App. >>> >>> To take an hypothetical example, if I use a particular app for logging >>> work, and log something last thing on a Friday . I then lock my phone, >>> which puts the App into the background. >>> The weekend staff take over on Saturday and pick up where I left off. >>> However, my changes never got synced so they end up repeating some work I >>> did. >>> Having some background sync, even if it was every 15 minutes ,could help >>> prevent this situation . >>> >>> On Tue, 15 Aug 2017 17:58 Wei Li, wrote: >>> >>>> I don't think it's necessary to run sync with high frequency when it's >>>> in the background mode. The app is not being used by the user, so no one >>>> cares if the data is actually up to date in the background. >>>> From this point of view, I think it's ok to use the JobScheduler when >>>> it's in background. It probably will use less battery as well (I think >>>> perhaps we can reduce the frequency of sync when it's running in the >>>> background for old Android versions too?). >>>> >>>> However users do expect the data is up to date ASAP when the app is in >>>> foreground mode. So this change is made, we probably should explain how >>>> developers can still achieve relatively good UX when the app is in the >>>> foreground again. >>>> We can either: >>>> * make sure sync API is called automatically when the app is brought >>>> into foreground. Or, >>>> * provide documents & code sample of how to invoke the sync API when >>>> the app is in foreground mode. >>>> >>>> My 2 cents... >>>> >>>> Thanks, >>>> >>>> On Tue, Aug 15, 2017 at 5:34 PM, Summers Pittman >>>> wrote: >>>> >>>>> So fh-android-sdk uses a polling thread with a one second timeout to >>>>> perform sync operations. While the application is in the foreground this >>>>> is fine since this thread just checks the Sync configuration and makes HTTP >>>>> calls to sync if a sync timeout has been reached. Because we want a >>>>> real-ish time experience our demos keep this timeout rather low. >>>>> >>>>> Prior to Android O when the application is in the background these >>>>> aggressive sync timeouts keep the local data updated until the application >>>>> is killed by the system. After Android O those requests fail and will >>>>> begin to call the failure callback while the application is backgrounded.* >>>>> The way that Google advises apps to work around this is to use the >>>>> JobScheduler APIs. >>>>> >>>>> JobScheduler has one downside though, you can't schedule background >>>>> tasks to run as frequently as the sync APIs want to run. I believe the >>>>> minimum is once every 15 minutes. For polling from the background this >>>>> probably isn't a big deal especially if there is a way to return the app to >>>>> a more aggressive state when it is in the foreground. >>>>> >>>>> For the next sprint the client SDK team is looking at implementing >>>>> JobScheduler for sync because this will make the sync APIs work better in >>>>> Android O. Does anyone have any objection/points of discussion or >>>>> clarification to the behavior and restrictions I mentioned? >>>>> >>>>> Thanks, >>>>> >>>>> Summers >>>>> >>>>> * Specifically if the phone has gone into Doze mode. >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> WEI LI >>>> >>>> SENIOR SOFTWARE ENGINEER >>>> >>>> Red Hat Mobile >>>> >>>> weil at redhat.com M: +353862393272 >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>> >> >> >> -- >> >> WEI LI >> >> SENIOR SOFTWARE ENGINEER >> >> Red Hat Mobile >> >> weil at redhat.com M: +353862393272 >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acarmona at redhat.com Thu Aug 17 14:08:42 2017 From: acarmona at redhat.com (Andrea Carmona) Date: 17 Aug 2017 10:08:42 -0400 Subject: [feedhenry-dev] =?utf-8?q?Don=E2=80=99t_Miss_the_Red_Hat_DevNatio?= =?utf-8?q?n_Live_Session_-_Sidecars_and_Microservices_Mesh?= Message-ID: <4b6cf77395c349fc98f3e293330fc462@1795> If you have trouble viewing this email, read the online version . "Red Hat" Hi RedHat Are you ready to attend the Red Hat DevNation live session Sidecars and Microservices Mesh, presented by Christian Posta? Join us today at 12 pm EST for this thirty minute session. Register Now For more information and to view the schedule, click here . We hope you join us! Regards, Andrea Carmona The Red Hat Developer Program __________________________________________________________________ [f1]Contact our sales team [f2]Manage your newsletter preferences [f3]Read our privacy policy [f4]Unsubscribe from all Red Hat email "Red Hat" and the "Shadowman" logo are trademarks or registered trademarks of Red Hat, Inc. Linux is a registered trademark of Linus Torvalds. ? 2016 Red Hat, Inc. All rights reserved. 100 East Davie Street Raleigh, NC 27601 [f5][twitter.png] [f6][facebook.png] [f7][redhat.png] References f1. http://www.redhat.com/apps/webform.html?event_type=contact_sales&eid=21 f2. https://www.redhat.com/wapps/ugc/email-subscriptions.html?elqc=241&elq=4b6cf77395c349fc98f3e293330fc462 f3. http://www.redhat.com/legal/privacy_statement.html f4. https://www.redhat.com/wapps/ugc/master-unsubscribe.html?elqc=241&elq=4b6cf77395c349fc98f3e293330fc462 f5. http://www.twitter.com/redhatnews f6. http://www.facebook.com/pages/Red-Hat/11218770329 f7. http://www.redhat.com/community/?sc_cid=70160000000I9TnAAK -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Aug 18 11:15:58 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 18 Aug 2017 12:15:58 +0100 Subject: [feedhenry-dev] Mobile Control Panel (5.x) First Look Message-ID: Hi all, I'm pleased to share a first look at the Mobile Control Panel. We are nearly 1 month into the development and would like to share what we have and get your feedback. This is a 3 month POC that aims to become the foundation for RH Mobile 5.0. So, here's a 10 minute video that shows what we have https://bluejeans.com/s/Wa5rX Video TLDR; The Mobile Control Panel (MCP) helps you setup a Mobile Service (Sync) in OpenShift and integrate a Cordova App with the provisioned Sync service. I'm look forward to any feedback (good & bad). If you would like to poke around, please check out the source at https://github.com/feedhenry/mobile-control-panel The video was based off this PR https://github.com/feedhenry/mobile-control-panel/pull/27. So once that lands (hopefully later today), you can try it out. If you have any questions, you can ask right here or on #feedhenry irc on freenode. Thanks -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Fri Aug 18 14:30:52 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Fri, 18 Aug 2017 15:30:52 +0100 Subject: [feedhenry-dev] Mobile Control Panel (5.x) First Look In-Reply-To: References: Message-ID: Demo looks really awesome. I just have couple questions that will help me to understand basic concepts. 1) What's the biggest difference between mobile-panel and creating openshift template to be available in standard UI? I see that we done UI modifications, but I'm mostly interested how this can be extended. Can we for example have push service that will have some UI elements to send push notification? 2) What is the main purpose of the mobile app? Want to make sure that I undestand the concept properly. Having mobile app in container platform may mean many things. Is that used as something like "RHMAP connection tag"? 3) Are looking to get some community contributors as well or is too early? 4) Do you think we can push example you demoing to sync-js repo? - it looks awesome! It's the best looking sync example I seen so far. Regards WOJCIECH TROCKI Red Hat Mobile IM: wtrocki On Fri, Aug 18, 2017 at 12:15 PM, David Martin wrote: > Hi all, > > I'm pleased to share a first look at the Mobile Control Panel. > We are nearly 1 month into the development and would like to share what we > have and get your feedback. > This is a 3 month POC that aims to become the foundation for RH Mobile 5.0. > > So, here's a 10 minute video that shows what we have > https://bluejeans.com/s/Wa5rX > > Video TLDR; > The Mobile Control Panel (MCP) helps you setup a Mobile Service (Sync) in > OpenShift and integrate a Cordova App with the provisioned Sync service. > > > I'm look forward to any feedback (good & bad). > If you would like to poke around, please check out the source at > https://github.com/feedhenry/mobile-control-panel > The video was based off this PR https://github.com/feedhenr > y/mobile-control-panel/pull/27. > So once that lands (hopefully later today), you can try it out. > > If you have any questions, you can ask right here or on #feedhenry irc on > freenode. > > > Thanks > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Aug 18 14:48:12 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 18 Aug 2017 15:48:12 +0100 Subject: [feedhenry-dev] Mobile Control Panel (5.x) First Look In-Reply-To: References: Message-ID: Hey Wojciech, Thanks for the questions. I've left some comments inline below. On 18 August 2017 at 15:30, Wojciech Trocki wrote: > Demo looks really awesome. I just have couple questions that will help me > to understand basic concepts. > > 1) What's the biggest difference between mobile-panel and creating > openshift template to be available in standard UI? > I see that we done UI modifications, but I'm mostly interested how this > can be extended. > Can we for example have push service that will have some UI elements to > send push notification? > We're leverage OpenShift UI extensions to do a few things: - adding the Mobile category for the Service Catalog - adding the 'Mobile' left nav item - allowing custom javascript, css & html to be loaded from a location configured on the openshift master By having custom javascript, we can add or even override AngularJS routes, templates etc... However, that's a lot of power, and could lead to incompatibilities with future OpenShift versions More info on this approach here https://docs.openshift.com/container-platform/3.6/install_config/web_console_customization.html and here https://github.com/feedhenry/mobile-control-panel/blob/master/ui/public/mcp.js > > > 2) What is the main purpose of the mobile app? > Want to make sure that I undestand the concept properly. Having mobile app > in container platform may mean many things. Is that used as something > like "RHMAP connection tag"? > Yeah, I think its a little early for the idea of a Mobile App being represented in Openshift to make sense. I think an RHMAP connection tag is a reasonable comparison, particularly if we went with a 'phone home on startup' approach to dynamically configure the App. Something to work out i think. > > 3) Are looking to get some community contributors as well or is too early? > Always! Its open season I say :) Check out the 'good first contributions' tag on github issues if you like. Or if you just want to play around and find some bugs & fix em, Super! https://github.com/feedhenry/mobile-control-panel/issues > > 4) Do you think we can push example you demoing to sync-js repo? - it > looks awesome! > It's the best looking sync example I seen so far. > Do you mean link to the video from the repo, or do something else? I've no problem with linking to the video. The code being used for the client, server & sample app are all on github already. https://github.com/feedhenry/fh-sync-js https://github.com/feedhenry/fh-sync-server https://github.com/feedhenry-templates/feedhenry-cordova-sync-app > Regards > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > On Fri, Aug 18, 2017 at 12:15 PM, David Martin > wrote: > >> Hi all, >> >> I'm pleased to share a first look at the Mobile Control Panel. >> We are nearly 1 month into the development and would like to share what >> we have and get your feedback. >> This is a 3 month POC that aims to become the foundation for RH Mobile >> 5.0. >> >> So, here's a 10 minute video that shows what we have >> https://bluejeans.com/s/Wa5rX >> >> Video TLDR; >> The Mobile Control Panel (MCP) helps you setup a Mobile Service (Sync) in >> OpenShift and integrate a Cordova App with the provisioned Sync service. >> >> >> I'm look forward to any feedback (good & bad). >> If you would like to poke around, please check out the source at >> https://github.com/feedhenry/mobile-control-panel >> The video was based off this PR https://github.com/feedhenr >> y/mobile-control-panel/pull/27. >> So once that lands (hopefully later today), you can try it out. >> >> If you have any questions, you can ask right here or on #feedhenry irc on >> freenode. >> >> >> Thanks >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Fri Aug 18 14:55:48 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Fri, 18 Aug 2017 15:55:48 +0100 Subject: [feedhenry-dev] Mobile Control Panel (5.x) First Look In-Reply-To: References: Message-ID: Thanks for answers. > Do you mean link to the video from the repo, or do something else? I was looking for sync demo app you were using in demo, but I see now that is already being published to feedhenry. Great work! WOJCIECH TROCKI Red Hat Mobile IM: wtrocki On Fri, Aug 18, 2017 at 3:48 PM, David Martin wrote: > Hey Wojciech, > > Thanks for the questions. > I've left some comments inline below. > > On 18 August 2017 at 15:30, Wojciech Trocki wrote: > >> Demo looks really awesome. I just have couple questions that will help me >> to understand basic concepts. >> >> 1) What's the biggest difference between mobile-panel and creating >> openshift template to be available in standard UI? >> I see that we done UI modifications, but I'm mostly interested how this >> can be extended. >> Can we for example have push service that will have some UI elements to >> send push notification? >> > We're leverage OpenShift UI extensions to do a few things: > - adding the Mobile category for the Service Catalog > - adding the 'Mobile' left nav item > - allowing custom javascript, css & html to be loaded from a location > configured on the openshift master > > By having custom javascript, we can add or even override AngularJS routes, > templates etc... > However, that's a lot of power, and could lead to incompatibilities with > future OpenShift versions > > More info on this approach here https://docs.openshift. > com/container-platform/3.6/install_config/web_console_customization.html > and here > https://github.com/feedhenry/mobile-control-panel/blob/ > master/ui/public/mcp.js > > > >> >> >> 2) What is the main purpose of the mobile app? >> Want to make sure that I undestand the concept properly. Having mobile >> app in container platform may mean many things. Is that used as >> something like "RHMAP connection tag"? >> > Yeah, I think its a little early for the idea of a Mobile App being > represented in Openshift to make sense. > I think an RHMAP connection tag is a reasonable comparison, particularly > if we went with a 'phone home on startup' approach to dynamically configure > the App. > Something to work out i think. > > >> >> 3) Are looking to get some community contributors as well or is too early? >> > Always! Its open season I say :) > Check out the 'good first contributions' tag on github issues if you like. > Or if you just want to play around and find some bugs & fix em, Super! > https://github.com/feedhenry/mobile-control-panel/issues > > >> >> 4) Do you think we can push example you demoing to sync-js repo? - it >> looks awesome! >> It's the best looking sync example I seen so far. >> > Do you mean link to the video from the repo, or do something else? > I've no problem with linking to the video. > The code being used for the client, server & sample app are all on github > already. > https://github.com/feedhenry/fh-sync-js > https://github.com/feedhenry/fh-sync-server > https://github.com/feedhenry-templates/feedhenry-cordova-sync-app > > >> Regards >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> >> On Fri, Aug 18, 2017 at 12:15 PM, David Martin >> wrote: >> >>> Hi all, >>> >>> I'm pleased to share a first look at the Mobile Control Panel. >>> We are nearly 1 month into the development and would like to share what >>> we have and get your feedback. >>> This is a 3 month POC that aims to become the foundation for RH Mobile >>> 5.0. >>> >>> So, here's a 10 minute video that shows what we have >>> https://bluejeans.com/s/Wa5rX >>> >>> Video TLDR; >>> The Mobile Control Panel (MCP) helps you setup a Mobile Service (Sync) >>> in OpenShift and integrate a Cordova App with the provisioned Sync service. >>> >>> >>> I'm look forward to any feedback (good & bad). >>> If you would like to poke around, please check out the source at >>> https://github.com/feedhenry/mobile-control-panel >>> The video was based off this PR https://github.com/feedhenr >>> y/mobile-control-panel/pull/27. >>> So once that lands (hopefully later today), you can try it out. >>> >>> If you have any questions, you can ask right here or on #feedhenry irc >>> on freenode. >>> >>> >>> Thanks >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (feedhenry, mobile-internal) >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Fri Aug 25 14:33:44 2017 From: weil at redhat.com (Wei Li) Date: Fri, 25 Aug 2017 15:33:44 +0100 Subject: [feedhenry-dev] Authentication in Mobile.Next Message-ID: Hi FeedHenry developers, As you may have heard, we are planning on delivering a few mobile-focused services in Mobile.Next project. One of the services we are looking at is authentication. As a start, we first would like to kick off some discussions around requirements & expectations of this service within the community. More specifically, we are looking for some answers to the following questions: * What is the biggest pain point you currently have in terms of user authentication when develop mobile applications? * What features/functions around authentication you should like to see in Mobile.Next, both client and cloud side? * If you have used Keycloak before, what is your thoughts on integration with it in mobile applications? * Anything else around authentication? The answers to those questions will help us make sure we deliver something that will solve the problems you are facing day to day. We look forward to your answers and thank you in advance. Regards, -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Fri Aug 25 15:47:28 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Fri, 25 Aug 2017 16:47:28 +0100 Subject: [feedhenry-dev] Authentication in Mobile.Next In-Reply-To: References: Message-ID: Hi Wei I'm not really 'external' developer, but I'm heavily invested in that area so wanted to share my thoughts. On Fri, Aug 25, 2017 at 3:33 PM, Wei Li wrote: > Hi FeedHenry developers, > > As you may have heard, we are planning on delivering a few mobile-focused > services in Mobile.Next project. One of the services we are looking at is > authentication. > > As a start, we first would like to kick off some discussions around > requirements & expectations of this service within the community. More > specifically, we are looking for some answers to the following questions: > > * What is the biggest pain point you currently have in terms of user > authentication when develop mobile applications? > *From what I have seen so far most of the problems I encountered can be assigned to two categories:* - Legacy, custom auth in the cloud. Difficult to integrate authentication with user sources. - SDK's are build with assumption that some particular security solution (FH_AUTH_... headers e.g.) is being used (Lack of choices on the client) > * What features/functions around authentication you should like to see in > Mobile.Next, both client and cloud side? > *RHMAP specific **functionalities**: * *- Authentication detached from SDK's * For example by creating auth service (keycloak). Lightweight aproach (for example using JWT in node.js server) should still be possible - let's avoid hard dependency to security service. *- Pluggable auth* Feedhenry libraries should have clear and documented path that will properly explain how authentication and authorization can be added. *- Local setup (development)* IMHO We should provide options to work when this service is not provisioned (development, local setup etc.) *Keycloak specific functionalities (little bit outside auth area)* *- Preconfigured realm with "suggested security options"* Create realms that will come with the best security practices. This realms, may be used as template for creating some specific app type (mobile, website etc.) *- Automatic creation of client when deploying new template (depending on type)* We can associate client with mobile/website template and create separate one if needed. This will reduce amount of boilerplate and will allow us to support "default" authentication. It will work nice with demos and simplify overall getting started experience. *- Templates that promote best security patterns (PIN, secure file storage, encrypted sync and work with default realm)* This may not be related to auth, but I think it's best to have template that will include "best security practices" and can be used as base for projects. Everything to improve getting started experience with Keycloak and RHMAP. *- Supporting keycloak customization (if possible)* Users should be able to provide custom login page (probably requires s2i build), change configuration, add user federations without breaking RHMAP integration. IMHO we should allow developers to configure keycloak as they wish without breaking other services and that may be the challenge. > * If you have used Keycloak before, what is your thoughts on integration > with it in mobile applications? > Keycloak usability depends on the platform (website, cordova, android etc.). Some of the functionalities may not be available on the mobile etc. Keycloak auth is really specific as most of their documentation and demos focus on customized login page (which is website) The biggest pain point with keycloak IMHO is that it needs to be strongly integrated with your app. For example integrated keycloak is adding lots of random data into URL which breaks most of the javascript frameworks that use hash routers. Users lose control over the login page etc. When using token based aproach this problems will disappear, but this may be difficult for beginners. Another pain point is that to make some modifications around user federations, login page and themes require physical changes in container - like dropping jar. It's not that this will hit our customers but it may be painful to orchestrate to our service architecture. Another problem you may hit is that keycloak seems to be more centralized single sign on solution - where companies and corporations have single instance of it to deal with all auth problems in organization. If we start spinning multiple services we need to think about granularity and duplication of user data issues that may appear. You probably have all of this sorted, but wanted to mention that just in case. IMHO the biggest challenge here is to get something generic as it will mean that some particular choices will need to be made for developers. Keycloak is pretty good and generic framework on his own that can be setup and configured in short amount of time. Most of the work required to setup keycloak will be related with actual configuration (realms, groups etc.) that is hard to generalize. I think that I might be missing the main point here: *What will be the end user value or set of technical problems team want to resolve by having Keycloak service over the standard keycloak template deployed to OpenShift?* *What kind of level of configuration and automation team want to provide (Should user create their realms etc.?)* *Do we plan to enable security for our templates outside the box?* > * Anything else around authentication? > Do we plan to do Authorization? > > The answers to those questions will help us make sure we deliver something > that will solve the problems you are facing day to day. > > We look forward to your answers and thank you in advance. > > Regards, > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Fri Aug 25 16:08:54 2017 From: supittma at redhat.com (Summers Pittman) Date: Fri, 25 Aug 2017 12:08:54 -0400 Subject: [feedhenry-dev] Authentication in Mobile.Next In-Reply-To: References: Message-ID: On Fri, Aug 25, 2017 at 10:33 AM, Wei Li wrote: > Hi FeedHenry developers, > > As you may have heard, we are planning on delivering a few mobile-focused > services in Mobile.Next project. One of the services we are looking at is > authentication. > > As a start, we first would like to kick off some discussions around > requirements & expectations of this service within the community. More > specifically, we are looking for some answers to the following questions: > > * What is the biggest pain point you currently have in terms of user > authentication when develop mobile applications? > My biggest pain is integrating in various social providers in a way that is compatible and not clunky, For a new app there is an understood Register -> Confirm Registration -> Log In -> Use the app flow. Social providers through OAuth combine the first three steps into a single step (select the account to use), but integrating with each provider is often very time consuming. Keycloak manages a lot of the social flow, but it does not have a native experience and falls back to OAuth 2 web flow. It is a bad user experience (and bad for user retention) if the first thing they do after they open your app they just downloaded if they are taken out of the app to sign into a website. > * What features/functions around authentication you should like to see in > Mobile.Next, both client and cloud side? > Better support for real time authentication events, asynchronous sessions, and WebSockets. On the client side we need support for Native platforms in a way that doesn't rely on WebViews. We also need better exposure of best practices because the native platform gives us more options than the cookie store in a web browser does. For instance tokens can be kept in a biometrically sealed keystore which require the user to use a thumbprint to unlock before the app can perform an operation. > * If you have used Keycloak before, what is your thoughts on integration > with it in mobile applications? > Keycloak is pure magical wonderfulness for Java EE Servers and web based applications. Outside of this there is a lot of compatibility thanks to some smart design choices, but the documentation isn't great at explaining that. Most of my googling for how to do something in KC often turns up my own blog posts ><. On Android KC is only OK. It is really missing support for using the Google account found on most devices. You can work around this by using webviews, redirects, etc to get this information but there isn't a golden scenario. > * Anything else around authentication? > I feel like we are 80% there already. We need good docs and examples for non trivial integrations. The learning curve is really steep because the problem is really complex and requires a lot of integrations. If we can just support a few of those with sensible defaults that are easy to change then I think we can make a lot of headway. > > The answers to those questions will help us make sure we deliver something > that will solve the problems you are facing day to day. > > We look forward to your answers and thank you in advance. > > Regards, > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Mon Aug 28 14:01:55 2017 From: supittma at redhat.com (Summers Pittman) Date: Mon, 28 Aug 2017 10:01:55 -0400 Subject: [feedhenry-dev] Authentication in Mobile.Next In-Reply-To: References: Message-ID: It sounds like between the meeting and this thread we have some really good lines of investigation to pursue. If you guys are up for it, we can have a meeting tomorrow ~1430 (0930 ET) and fill out some spikes in a jira portfolio to begin actual work. Ping me on this thread, IRC, or slack and I will send you a meeting invite. On Fri, Aug 25, 2017 at 12:08 PM, Summers Pittman wrote: > > > On Fri, Aug 25, 2017 at 10:33 AM, Wei Li wrote: > >> Hi FeedHenry developers, >> >> As you may have heard, we are planning on delivering a few mobile-focused >> services in Mobile.Next project. One of the services we are looking at is >> authentication. >> >> As a start, we first would like to kick off some discussions around >> requirements & expectations of this service within the community. More >> specifically, we are looking for some answers to the following questions: >> >> * What is the biggest pain point you currently have in terms of user >> authentication when develop mobile applications? >> > > My biggest pain is integrating in various social providers in a way that > is compatible and not clunky, > > For a new app there is an understood Register -> Confirm Registration -> > Log In -> Use the app flow. Social providers through OAuth combine the > first three steps into a single step (select the account to use), but > integrating with each provider is often very time consuming. > > Keycloak manages a lot of the social flow, but it does not have a native > experience and falls back to OAuth 2 web flow. It is a bad user experience > (and bad for user retention) if the first thing they do after they open > your app they just downloaded if they are taken out of the app to sign into > a website. > > >> * What features/functions around authentication you should like to see in >> Mobile.Next, both client and cloud side? >> > > Better support for real time authentication events, asynchronous sessions, > and WebSockets. > > On the client side we need support for Native platforms in a way that > doesn't rely on WebViews. We also need better exposure of best practices > because the native platform gives us more options than the cookie store in > a web browser does. For instance tokens can be kept in a biometrically > sealed keystore which require the user to use a thumbprint to unlock before > the app can perform an operation. > > > >> * If you have used Keycloak before, what is your thoughts on integration >> with it in mobile applications? >> > > Keycloak is pure magical wonderfulness for Java EE Servers and web based > applications. Outside of this there is a lot of compatibility thanks to > some smart design choices, but the documentation isn't great at explaining > that. Most of my googling for how to do something in KC often turns up my > own blog posts ><. > > On Android KC is only OK. It is really missing support for using the > Google account found on most devices. You can work around this by using > webviews, redirects, etc to get this information but there isn't a golden > scenario. > > >> * Anything else around authentication? >> > > I feel like we are 80% there already. We need good docs and examples for > non trivial integrations. The learning curve is really steep because the > problem is really complex and requires a lot of integrations. If we can > just support a few of those with sensible defaults that are easy to change > then I think we can make a lot of headway. > >> >> The answers to those questions will help us make sure we deliver >> something that will solve the problems you are facing day to day. >> >> We look forward to your answers and thank you in advance. >> >> Regards, >> >> -- >> >> WEI LI >> >> SENIOR SOFTWARE ENGINEER >> >> Red Hat Mobile >> >> weil at redhat.com M: +353862393272 >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Mon Aug 28 15:43:01 2017 From: weil at redhat.com (Wei Li) Date: Mon, 28 Aug 2017 16:43:01 +0100 Subject: [feedhenry-dev] Authentication in Mobile.Next In-Reply-To: References: Message-ID: On Fri, Aug 25, 2017 at 4:47 PM, Wojciech Trocki wrote: > Hi Wei > > I'm not really 'external' developer, but I'm heavily invested in that area > so wanted to share my thoughts. > > On Fri, Aug 25, 2017 at 3:33 PM, Wei Li wrote: > >> Hi FeedHenry developers, >> >> As you may have heard, we are planning on delivering a few mobile-focused >> services in Mobile.Next project. One of the services we are looking at is >> authentication. >> >> As a start, we first would like to kick off some discussions around >> requirements & expectations of this service within the community. More >> specifically, we are looking for some answers to the following questions: >> >> * What is the biggest pain point you currently have in terms of user >> authentication when develop mobile applications? >> > > *From what I have seen so far most of the problems I encountered can be > assigned to two categories:* > > - Legacy, custom auth in the cloud. Difficult to integrate authentication > with user sources. > - SDK's are build with assumption that some particular security solution > (FH_AUTH_... headers e.g.) is being used (Lack of choices on the client) > Looks like these are about using the existing auth function of the platform. Sorry I didn't make it clear but what I am looking for here is not about using FH.auth, but in general - e.g. What are the pain points/problems when you need to implement user authentication in a mobile application (that may not use FH.auth/RHMAP)? FH.Auth is deprecated and we are looking at a new implementation for Mobile.Next. > > >> * What features/functions around authentication you should like to see in >> Mobile.Next, both client and cloud side? >> > > *RHMAP specific **functionalities**: * > > *- Authentication detached from SDK's * > For example by creating auth service (keycloak). > Lightweight aproach (for example using JWT in node.js server) should still > be possible - let's avoid hard dependency to security service. > > *- Pluggable auth* > Feedhenry libraries should have clear and documented path that will > properly explain how authentication and authorization can be added. > > *- Local setup (development)* > IMHO We should provide options to work when this service is not > provisioned (development, local setup etc.) > > *Keycloak specific functionalities (little bit outside auth area)* > > *- Preconfigured realm with "suggested security options"* > Create realms that will come with the best security practices. > This realms, may be used as template for creating some specific app type > (mobile, website etc.) > +1. I think for a non-security expert, Keycloak is not really that easy to use. We need to figure out something to make it as easy as possible to setup, or "just work". Creating/configuring sample realms sounds like a good approach to explore. > > *- Automatic creation of client when deploying new template (depending on > type)* > We can associate client with mobile/website template and create separate > one if needed. > This will reduce amount of boilerplate and will allow us to support > "default" authentication. > It will work nice with demos and simplify overall getting started > experience. > > *- Templates that promote best security patterns (PIN, secure file > storage, encrypted sync and work with default realm)* > This may not be related to auth, but I think it's best to have template > that will include "best security practices" and can be used as base for > projects. > Everything to improve getting started experience with Keycloak and RHMAP. > Yes, this is the aim of the mobile security project we are working on at the moment. > > *- Supporting keycloak customization (if possible)* > Users should be able to provide custom login page (probably requires s2i > build), change configuration, add user federations without breaking RHMAP > integration. > IMHO we should allow developers to configure keycloak as they wish without > breaking other services and that may be the challenge. > > > >> * If you have used Keycloak before, what is your thoughts on integration >> with it in mobile applications? >> > > > Keycloak usability depends on the platform (website, cordova, android > etc.). > Some of the functionalities may not be available on the mobile etc. > > Keycloak auth is really specific as most of their documentation and demos > focus on customized login page (which is website) > > The biggest pain point with keycloak IMHO is that it needs to be > strongly integrated with your app. > For example integrated keycloak is adding lots of random data into URL > which breaks most of the javascript frameworks that use hash routers. > Users lose control over the login page etc. When using token based aproach > this problems will disappear, but this may be difficult for beginners. > > Another pain point is that to make some modifications around user > federations, login page and themes require physical changes in container - > like dropping jar. > It's not that this will hit our customers but it may be painful to > orchestrate to our service architecture. > > Another problem you may hit is that keycloak seems to be more centralized > single sign on solution - where companies and corporations have single > instance of it > to deal with all auth problems in organization. If we start spinning > multiple services we need to think about granularity and duplication of > user data issues that may appear. > You probably have all of this sorted, but wanted to mention that just in > case. > > IMHO the biggest challenge here is to get something generic as it will > mean that some particular choices will need to be made for developers. > Keycloak is pretty good and generic framework on his own that can be setup > and configured in short amount of time. > Most of the work required to setup keycloak will be related with actual > configuration (realms, groups etc.) that is hard to generalize. > > I think that I might be missing the main point here: > *What will be the end user value or set of technical problems team want to > resolve by having Keycloak service over the standard keycloak template > deployed to OpenShift?* > It probably will be the same Keycloak, but optimised for mobile applications. In my view, the ideal scenario would be that a developer enables the service, no configuration required, just download the configuration file, add the client side library into the mobile application and done. For all the other services, the request authentications are handled automatically. There might be some other configurations that they can change, but those should be well documented, and the users don't need to know Keycloak if they don't want to. > *What kind of level of configuration and automation team want to provide > (Should user create their realms etc.?)* > In my view, as much as we can to the point where it will just work by default. > *Do we plan to enable security for our templates outside the box?* > Are we still talking about client templates? There will be some templates dedicated to demonstrate the best security practices, and hopefully all the templates will have some degree of security elements in them. > > >> * Anything else around authentication? >> > > Do we plan to do Authorization? > > I would say yes, but that's another discussion. > >> The answers to those questions will help us make sure we deliver >> something that will solve the problems you are facing day to day. >> >> We look forward to your answers and thank you in advance. >> >> Regards, >> >> -- >> >> WEI LI >> >> SENIOR SOFTWARE ENGINEER >> >> Red Hat Mobile >> >> weil at redhat.com M: +353862393272 >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsazel at redhat.com Tue Aug 29 12:12:20 2017 From: vsazel at redhat.com (Vojtech Sazel) Date: Tue, 29 Aug 2017 14:12:20 +0200 Subject: [feedhenry-dev] Sync decoupling from fh-android-sdk Message-ID: Hi, for those who don't know Dynamic SDK Team is now working on decoupling FH Sync SDK from fh-android-sdk. But not everyone probably know how is it dependent on rest of the SDK. I have few points from my little digging into it: 1) Good news is that there it's very little dependency on rest of the sdk. FH, FHActRequest, FHActCallback- for calling cloud service, basically only one method is used FHLog - for logging, wrapper for Android Log 2) Most difficult part would be to replace remote calls, but it's still quite easy. *For discussion: *Should we use *OkHttp* http client or more high level library like *Retrofit *? Or even use plain Java HttpsURLConnection or something else?? 3) Determining URL to cloud app after decoupling. *@wtrocki* How was this done in JS Sync SDK? 4) QE would like to have most functionality written platform independent (not dependent on Android SDK). Why to do that? We can have most tests running without emulator. This would result in much quicker and more stable execution. It's especially important when running tests on Circle CI, Jenkins or elsewhere. How to do that? We can have HTTP calls, logger and filesystem access written against interfaces. Then it can be implemented in Android or pure Java separately. Like this - https://github.com/feedhenry/fh-android-sdk/pull/107/commits/ae2c... This would also serve as PoC of proper design for other future SDKs for 5.x/mobile.next. Thanks for your suggestions. -- VOJT?CH S?ZEL SENIOR QUALITY ENGINEER, MOBILE QE Red Hat Remote Czech Republic vsazel at redhat.com IM: vsazel -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Tue Aug 29 12:31:04 2017 From: supittma at redhat.com (Summers Pittman) Date: Tue, 29 Aug 2017 08:31:04 -0400 Subject: [feedhenry-dev] Sync decoupling from fh-android-sdk In-Reply-To: References: Message-ID: On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel wrote: > Hi, > > for those who don't know Dynamic SDK Team is now working on decoupling FH > Sync SDK from fh-android-sdk. > > But not everyone probably know how is it dependent on rest of the SDK. I > have few points from my little digging into it: > 1) Good news is that there it's very little dependency on rest of the sdk. > FH, FHActRequest, FHActCallback- for calling cloud service, basically > only one method is used > FHLog - for logging, wrapper for Android Log > > 2) Most difficult part would be to replace remote calls, but it's still > quite easy. > *For discussion: *Should we use *OkHttp* http > client or more high level library like *Retrofit > *? Or even use plain Java > HttpsURLConnection or something else?? > > OKHttp because I think we will get a lot more milage out of that level of abstraction and the API is better (IMHO) and HttpsURLConnection. Retrofit's use cases are very tied to RESTful APIs and I'm not sure that RESTful is the future of sync. > 3) Determining URL to cloud app after decoupling. *@wtrocki* How was this > done in JS Sync SDK? > > 4) QE would like to have most functionality written platform independent > (not dependent on Android SDK). > Why to do that? We can have most tests running without emulator. This > would result in much quicker and more stable execution. It's especially > important when running tests on Circle CI, Jenkins or elsewhere. > How to do that? > We can have HTTP calls, logger and filesystem access written against > interfaces. Then it can be implemented in Android or pure Java separately. > Like this - https://github.com/feedhenry/fh-android-sdk/pull/107/ > commits/ae2c... > > -1 (ish). I agree with the sentament and some of the conclusions, but this is an Android SDK and going out of our way to make it NOT an Android SDK is a waste of time IMHO. Furthermore, Google has support for this exact use case in their testing docs ( https://developer.android.com/training/testing/unit-testing/local-unit-tests.html#mocking-dependencies). There are a few caveats to my -1 though. First if we want to make a JavaSDK for use with desktop or server to server applications then you have my interest and we should investigate that route. Second, if QE has looked at the testing tools available for Android and mocking their dependencies and found it to be lacking I defer to their judgement. Finally, good code should have firewalls between system services and logic anyway so there will be a lot of code that currently has dependencies on Android APIs that won't in the future. > > This would also serve as PoC of proper design for other future SDKs for > 5.x/mobile.next. > > Thanks for your suggestions. > > -- > > VOJT?CH S?ZEL > > SENIOR QUALITY ENGINEER, MOBILE QE > > Red Hat > > > > Remote Czech Republic > > vsazel at redhat.com IM: vsazel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Tue Aug 29 12:44:10 2017 From: dpassos at redhat.com (Daniel Passos) Date: Tue, 29 Aug 2017 09:44:10 -0300 Subject: [feedhenry-dev] Sync decoupling from fh-android-sdk In-Reply-To: References: Message-ID: On Tue, Aug 29, 2017 at 9:12 AM, Vojtech Sazel wrote: > Hi, > > for those who don't know Dynamic SDK Team is now working on decoupling FH > Sync SDK from fh-android-sdk. > > But not everyone probably know how is it dependent on rest of the SDK. I > have few points from my little digging into it: > 1) Good news is that there it's very little dependency on rest of the sdk. > FH, FHActRequest, FHActCallback- for calling cloud service, basically > only one method is used > FHLog - for logging, wrapper for Android Log > > 2) Most difficult part would be to replace remote calls, but it's still > quite easy. > *For discussion: *Should we use *OkHttp* http > client or more high level library like *Retrofit > *? Or even use plain Java > HttpsURLConnection or something else?? > I'd say let's use Retrofit, and if we need something specific let's use OkHttp since Retrofit is using it behind of the scene it will be there is we need. > > 3) Determining URL to cloud app after decoupling. *@wtrocki* How was this > done in JS Sync SDK? > > 4) QE would like to have most functionality written platform independent > (not dependent on Android SDK). > Why to do that? We can have most tests running without emulator. This > would result in much quicker and more stable execution. It's especially > important when running tests on Circle CI, Jenkins or elsewhere. > How to do that? > We can have HTTP calls, logger and filesystem access written against > interfaces. Then it can be implemented in Android or pure Java separately. > Like this - https://github.com/feedhenry/fh-android-sdk/pull/107/ > commits/ae2c... > > > This would also serve as PoC of proper design for other future SDKs for > 5.x/mobile.next. > > Thanks for your suggestions. > > -- > > VOJT?CH S?ZEL > > SENIOR QUALITY ENGINEER, MOBILE QE > > Red Hat > > > > Remote Czech Republic > > vsazel at redhat.com IM: vsazel > > -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From omatskiv at redhat.com Tue Aug 29 12:54:22 2017 From: omatskiv at redhat.com (Oleh Mackiv) Date: Tue, 29 Aug 2017 14:54:22 +0200 Subject: [feedhenry-dev] Sync decoupling from fh-android-sdk In-Reply-To: References: Message-ID: > > -1 (ish). I agree with the sentament and some of the conclusions, but > this is an Android SDK and going out of our way to make it NOT an Android > SDK is a waste of time IMHO. Furthermore, Google has support for this > exact use case in their testing docs (https://developer.android. > com/training/testing/unit-testing/local-unit-tests.html# > mocking-dependencies). > There are a few caveats to my -1 though. First if we want to make a > JavaSDK for use with desktop or server to server applications then you have > my interest and we should investigate that route. Second, if QE has looked > at the testing tools available for Android and mocking their dependencies > and found it to be lacking I defer to their judgement. Finally, good code > should have firewalls between system services and logic anyway so there > will be a lot of code that currently has dependencies on Android APIs that > won't in the future. > We would also like to eventually automate some integration tests, and "Java sync SDK" would be great for that. Android sync SDK would then use Java sync SDK and have only limited test set for integration/system tests. On Tue, Aug 29, 2017 at 2:31 PM, Summers Pittman wrote: > > > On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel wrote: > >> Hi, >> >> for those who don't know Dynamic SDK Team is now working on decoupling FH >> Sync SDK from fh-android-sdk. >> >> But not everyone probably know how is it dependent on rest of the SDK. I >> have few points from my little digging into it: >> 1) Good news is that there it's very little dependency on rest of the >> sdk. >> FH, FHActRequest, FHActCallback- for calling cloud service, basically >> only one method is used >> FHLog - for logging, wrapper for Android Log >> >> 2) Most difficult part would be to replace remote calls, but it's still >> quite easy. >> *For discussion: *Should we use *OkHttp* >> http client or more high level library >> like *Retrofit *? Or even use plain >> Java HttpsURLConnection or something else?? >> >> > OKHttp because I think we will get a lot more milage out of that level of > abstraction and the API is better (IMHO) and HttpsURLConnection. > Retrofit's use cases are very tied to RESTful APIs and I'm not sure that > RESTful is the future of sync. > > >> 3) Determining URL to cloud app after decoupling. *@wtrocki* How was >> this done in JS Sync SDK? >> >> 4) QE would like to have most functionality written platform independent >> (not dependent on Android SDK). >> Why to do that? We can have most tests running without emulator. This >> would result in much quicker and more stable execution. It's especially >> important when running tests on Circle CI, Jenkins or elsewhere. >> How to do that? >> We can have HTTP calls, logger and filesystem access written against >> interfaces. Then it can be implemented in Android or pure Java separately. >> Like this - https://github.com/feedhenry/fh-android-sdk/pull/107/commits >> /ae2c... >> >> > > -1 (ish). I agree with the sentament and some of the conclusions, but this > is an Android SDK and going out of our way to make it NOT an Android SDK is > a waste of time IMHO. Furthermore, Google has support for this exact use > case in their testing docs (https://developer.android. > com/training/testing/unit-testing/local-unit-tests.html# > mocking-dependencies). > > There are a few caveats to my -1 though. First if we want to make a > JavaSDK for use with desktop or server to server applications then you have > my interest and we should investigate that route. Second, if QE has looked > at the testing tools available for Android and mocking their dependencies > and found it to be lacking I defer to their judgement. Finally, good code > should have firewalls between system services and logic anyway so there > will be a lot of code that currently has dependencies on Android APIs that > won't in the future. > > > >> This would also serve as PoC of proper design for other future SDKs for >> 5.x/mobile.next. >> >> Thanks for your suggestions. >> >> -- >> >> VOJT?CH S?ZEL >> >> SENIOR QUALITY ENGINEER, MOBILE QE >> >> Red Hat >> >> >> >> Remote Czech Republic >> >> vsazel at redhat.com IM: vsazel >> >> > > -- Oleg Matskiv Associate Quality Engineer Red Hat Mobile Application Platform omatskiv at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsazel at redhat.com Tue Aug 29 13:09:53 2017 From: vsazel at redhat.com (Vojtech Sazel) Date: Tue, 29 Aug 2017 15:09:53 +0200 Subject: [feedhenry-dev] Sync decoupling from fh-android-sdk In-Reply-To: References: Message-ID: On Tue, Aug 29, 2017 at 2:54 PM, Oleh Mackiv wrote: > -1 (ish). I agree with the sentament and some of the conclusions, but >> this is an Android SDK and going out of our way to make it NOT an Android >> SDK is a waste of time IMHO. Furthermore, Google has support for this >> exact use case in their testing docs (https://developer.android.com >> /training/testing/unit-testing/local-unit-tests.html#mocking-dependencies). >> >> > There are a few caveats to my -1 though. First if we want to make a >> JavaSDK for use with desktop or server to server applications then you have >> my interest and we should investigate that route. Second, if QE has looked >> at the testing tools available for Android and mocking their dependencies >> and found it to be lacking I defer to their judgement. Finally, good code >> should have firewalls between system services and logic anyway so there >> will be a lot of code that currently has dependencies on Android APIs that >> won't in the future. >> > > We would also like to eventually automate some integration tests, and > "Java sync SDK" would be great for that. Android sync SDK would then use > Java sync SDK and have only limited test set for integration/system tests.> > It would be possible to use Robolectric, but as I said Android dependency was really almost unnecessary there in the first place. Only place it uses Android Context is for opening files for datasets. I think yes, Destop Java is dead but it still makes sense to have the logic of sync and Android logic separately. Just for clarity. It's really not a deadly amount of work to do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Tue Aug 29 13:10:39 2017 From: weil at redhat.com (Wei Li) Date: Tue, 29 Aug 2017 14:10:39 +0100 Subject: [feedhenry-dev] Sync decoupling from fh-android-sdk In-Reply-To: References: Message-ID: On Tue, Aug 29, 2017 at 1:12 PM, Vojtech Sazel wrote: > Hi, > > for those who don't know Dynamic SDK Team is now working on decoupling FH > Sync SDK from fh-android-sdk. > > But not everyone probably know how is it dependent on rest of the SDK. I > have few points from my little digging into it: > 1) Good news is that there it's very little dependency on rest of the sdk. > FH, FHActRequest, FHActCallback- for calling cloud service, basically > only one method is used > FHLog - for logging, wrapper for Android Log > > 2) Most difficult part would be to replace remote calls, but it's still > quite easy. > *For discussion: *Should we use *OkHttp* http > client or more high level library like *Retrofit > *? Or even use plain Java > HttpsURLConnection or something else?? > I would vote for OkHttp, as sync endpoints are not really RESTFUL endpoints. Using OkHttp provides more flexibility. > > 3) Determining URL to cloud app after decoupling. *@wtrocki* How was this > done in JS Sync SDK? > At the moment, the sync endpoints are always like this https:///mbaas/sync. I believe the url of the cloud app is passed in as part of the initialisation in the js sync sdk. For now, we should do the same for the android sync lib. In the long term, I think there should be another module that is responsible for service discovery - resolve the url of the services and pass the them to each service's module. > > 4) QE would like to have most functionality written platform independent > (not dependent on Android SDK). > Why to do that? We can have most tests running without emulator. This > would result in much quicker and more stable execution. It's especially > important when running tests on Circle CI, Jenkins or elsewhere. > How to do that? > We can have HTTP calls, logger and filesystem access written against > interfaces. Then it can be implemented in Android or pure Java separately. > Like this - https://github.com/feedhenry/fh-android-sdk/pull/107/commits > /ae2c... > > I think create interfaces to abstract some the android dependencies are fine, but that should be the aim for supporting another environment (e.g. Java), not for running the tests - to make sure the sdk is properly tested, we should run them in the emulators anyway. Creating the interfaces for the tests seems to be the wrong motivation (if we are running integration tests). > > This would also serve as PoC of proper design for other future SDKs for > 5.x/mobile.next. > > Thanks for your suggestions. > > -- > > VOJT?CH S?ZEL > > SENIOR QUALITY ENGINEER, MOBILE QE > > Red Hat > > > > Remote Czech Republic > > vsazel at redhat.com IM: vsazel > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Tue Aug 29 13:17:12 2017 From: supittma at redhat.com (Summers Pittman) Date: Tue, 29 Aug 2017 09:17:12 -0400 Subject: [feedhenry-dev] Sync decoupling from fh-android-sdk In-Reply-To: References: Message-ID: On Tue, Aug 29, 2017 at 9:09 AM, Vojtech Sazel wrote: > On Tue, Aug 29, 2017 at 2:54 PM, Oleh Mackiv wrote: > >> -1 (ish). I agree with the sentament and some of the conclusions, but >>> this is an Android SDK and going out of our way to make it NOT an Android >>> SDK is a waste of time IMHO. Furthermore, Google has support for this >>> exact use case in their testing docs (https://developer.android.com >>> /training/testing/unit-testing/local-unit-tests.html#mocking >>> -dependencies). >>> >> There are a few caveats to my -1 though. First if we want to make a >>> JavaSDK for use with desktop or server to server applications then you have >>> my interest and we should investigate that route. Second, if QE has looked >>> at the testing tools available for Android and mocking their dependencies >>> and found it to be lacking I defer to their judgement. Finally, good code >>> should have firewalls between system services and logic anyway so there >>> will be a lot of code that currently has dependencies on Android APIs that >>> won't in the future. >>> >> >> We would also like to eventually automate some integration tests, and >> "Java sync SDK" would be great for that. Android sync SDK would then use >> Java sync SDK and have only limited test set for integration/system tests.> >> > > It would be possible to use Robolectric, but as I said Android dependency > was really almost unnecessary there in the first place. Only place it uses > Android Context is for opening files for datasets. I think yes, Destop Java > is dead but it still makes sense to have the logic of sync and Android > logic separately. Just for clarity. It's really not a deadly amount of work > to do. > I think it is the right thing to do (coding to interfaces), I think making a separate SDK for testing is wrong. As an aside I am holding out hope that desktop Java is almost ready for a revival ;) . -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Tue Aug 29 14:54:07 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 29 Aug 2017 16:54:07 +0200 Subject: [feedhenry-dev] Sync decoupling from fh-android-sdk In-Reply-To: References: Message-ID: On Tue, Aug 29, 2017 at 2:31 PM, Summers Pittman wrote: > > > On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel wrote: > >> Hi, >> >> for those who don't know Dynamic SDK Team is now working on decoupling FH >> Sync SDK from fh-android-sdk. >> >> But not everyone probably know how is it dependent on rest of the SDK. I >> have few points from my little digging into it: >> 1) Good news is that there it's very little dependency on rest of the >> sdk. >> FH, FHActRequest, FHActCallback- for calling cloud service, basically >> only one method is used >> FHLog - for logging, wrapper for Android Log >> >> 2) Most difficult part would be to replace remote calls, but it's still >> quite easy. >> *For discussion: *Should we use *OkHttp* >> http client or more high level library >> like *Retrofit *? Or even use plain >> Java HttpsURLConnection or something else?? >> >> > OKHttp because I think we will get a lot more milage out of that level of > abstraction and the API is better (IMHO) and HttpsURLConnection. > +1 also offers Http/2 support, for more real-time nature > Retrofit's use cases are very tied to RESTful APIs and I'm not sure that > RESTful is the future of sync. > > >> 3) Determining URL to cloud app after decoupling. *@wtrocki* How was >> this done in JS Sync SDK? >> >> 4) QE would like to have most functionality written platform independent >> (not dependent on Android SDK). >> Why to do that? We can have most tests running without emulator. This >> would result in much quicker and more stable execution. It's especially >> important when running tests on Circle CI, Jenkins or elsewhere. >> How to do that? >> We can have HTTP calls, logger and filesystem access written against >> interfaces. Then it can be implemented in Android or pure Java separately. >> Like this - https://github.com/feedhenry/fh-android-sdk/pull/107/commits >> /ae2c... >> >> > > -1 (ish). I agree with the sentament and some of the conclusions, but > this is an Android SDK and going out of our way to make it NOT an Android > SDK is a waste of time IMHO. Furthermore, Google has support for this > exact use case in their testing docs (https://developer.android. > com/training/testing/unit-testing/local-unit-tests.html# > mocking-dependencies). > > There are a few caveats to my -1 though. First if we want to make a > JavaSDK for use with desktop or server to server applications then you have > my interest and we should investigate that route. Second, if QE has looked > at the testing tools available for Android and mocking their dependencies > and found it to be lacking I defer to their judgement. Finally, good code > should have firewalls between system services and logic anyway so there > will be a lot of code that currently has dependencies on Android APIs that > won't in the future. > -1 as well, like summers said, this is Android, and should not be treated like a lib that is sitting in a Java6 server (e.g. usage of HttpsUrlConnection) -M > > >> >> This would also serve as PoC of proper design for other future SDKs for >> 5.x/mobile.next. >> >> Thanks for your suggestions. >> >> -- >> >> VOJT?CH S?ZEL >> >> SENIOR QUALITY ENGINEER, MOBILE QE >> >> Red Hat >> >> >> >> Remote Czech Republic >> >> vsazel at redhat.com IM: vsazel >> >> > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Tue Aug 29 15:04:06 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 29 Aug 2017 17:04:06 +0200 Subject: [feedhenry-dev] Sync decoupling from fh-android-sdk In-Reply-To: References: Message-ID: On Tue, Aug 29, 2017 at 2:54 PM, Oleh Mackiv wrote: > -1 (ish). I agree with the sentament and some of the conclusions, but >> this is an Android SDK and going out of our way to make it NOT an Android >> SDK is a waste of time IMHO. Furthermore, Google has support for this >> exact use case in their testing docs (https://developer.android.com >> /training/testing/unit-testing/local-unit-tests.html#mocking-dependencies). >> >> > There are a few caveats to my -1 though. First if we want to make a >> JavaSDK for use with desktop or server to server applications then you have >> my interest and we should investigate that route. Second, if QE has looked >> at the testing tools available for Android and mocking their dependencies >> and found it to be lacking I defer to their judgement. Finally, good code >> should have firewalls between system services and logic anyway so there >> will be a lot of code that currently has dependencies on Android APIs that >> won't in the future. >> > > We would also like to eventually automate some integration tests, and > "Java sync SDK" would be great for that. Android sync SDK would then use > Java sync SDK and have only limited test set for integration/system tests. > currently we don't have the need for that. However, let's assume in the (near) future, there will be "cloud-apps", powered by a modern java-stack (e.g. vertx). The generic Java-SDK does not help you much here, since that's a completely different platform (e.g. rxjava etc) -M > > > On Tue, Aug 29, 2017 at 2:31 PM, Summers Pittman > wrote: > >> >> >> On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel wrote: >> >>> Hi, >>> >>> for those who don't know Dynamic SDK Team is now working on decoupling >>> FH Sync SDK from fh-android-sdk. >>> >>> But not everyone probably know how is it dependent on rest of the SDK. I >>> have few points from my little digging into it: >>> 1) Good news is that there it's very little dependency on rest of the >>> sdk. >>> FH, FHActRequest, FHActCallback- for calling cloud service, basically >>> only one method is used >>> FHLog - for logging, wrapper for Android Log >>> >>> 2) Most difficult part would be to replace remote calls, but it's still >>> quite easy. >>> *For discussion: *Should we use *OkHttp* >>> http client or more high level library >>> like *Retrofit *? Or even use plain >>> Java HttpsURLConnection or something else?? >>> >>> >> OKHttp because I think we will get a lot more milage out of that level of >> abstraction and the API is better (IMHO) and HttpsURLConnection. >> Retrofit's use cases are very tied to RESTful APIs and I'm not sure that >> RESTful is the future of sync. >> >> >>> 3) Determining URL to cloud app after decoupling. *@wtrocki* How was >>> this done in JS Sync SDK? >>> >>> 4) QE would like to have most functionality written platform independent >>> (not dependent on Android SDK). >>> Why to do that? We can have most tests running without emulator. This >>> would result in much quicker and more stable execution. It's especially >>> important when running tests on Circle CI, Jenkins or elsewhere. >>> How to do that? >>> We can have HTTP calls, logger and filesystem access written against >>> interfaces. Then it can be implemented in Android or pure Java separately. >>> Like this - https://github.com/feedhenry/fh-android-sdk/pull/107/commits >>> /ae2c... >>> >>> >> >> > -1 (ish). I agree with the sentament and some of the conclusions, but >> this is an Android SDK and going out of our way to make it NOT an Android >> SDK is a waste of time IMHO. Furthermore, Google has support for this >> exact use case in their testing docs (https://developer.android.com >> /training/testing/unit-testing/local-unit-tests.html#mocking-dependencies). >> >> >> > There are a few caveats to my -1 though. First if we want to make a >> JavaSDK for use with desktop or server to server applications then you have >> my interest and we should investigate that route. Second, if QE has looked >> at the testing tools available for Android and mocking their dependencies >> and found it to be lacking I defer to their judgement. Finally, good code >> should have firewalls between system services and logic anyway so there >> will be a lot of code that currently has dependencies on Android APIs that >> won't in the future. >> >> > >> >>> This would also serve as PoC of proper design for other future SDKs for >>> 5.x/mobile.next. >>> >>> Thanks for your suggestions. >>> >>> -- >>> >>> VOJT?CH S?ZEL >>> >>> SENIOR QUALITY ENGINEER, MOBILE QE >>> >>> Red Hat >>> >>> >>> >>> Remote Czech Republic >>> >>> vsazel at redhat.com IM: vsazel >>> >>> >> >> > > > -- > Oleg Matskiv > Associate Quality Engineer > Red Hat Mobile Application Platform > omatskiv at redhat.com > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Wed Aug 30 11:57:53 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Wed, 30 Aug 2017 12:57:53 +0100 Subject: [feedhenry-dev] Sync decoupling from fh-android-sdk In-Reply-To: References: Message-ID: Really good points. I can create PR for IOS and Android to extend this conversation to some example implementation. The major problem I see is how we going to include sync into existing SDK. For Android Sync will need to have their own network implementation and use adapter pattern for elements expected by SDK (FHActCallback etc.) IOS itself should be easier as we can use same network library and sdk can just include sync as lib itself. Regards Wojtek T. WOJCIECH TROCKI Red Hat Mobile IM: wtrocki On Tue, Aug 29, 2017 at 4:04 PM, Matthias Wessendorf wrote: > > > On Tue, Aug 29, 2017 at 2:54 PM, Oleh Mackiv wrote: > >> -1 (ish). I agree with the sentament and some of the conclusions, but >>> this is an Android SDK and going out of our way to make it NOT an Android >>> SDK is a waste of time IMHO. Furthermore, Google has support for this >>> exact use case in their testing docs (https://developer.android.com >>> /training/testing/unit-testing/local-unit-tests.html#mocking >>> -dependencies). >>> >> There are a few caveats to my -1 though. First if we want to make a >>> JavaSDK for use with desktop or server to server applications then you have >>> my interest and we should investigate that route. Second, if QE has looked >>> at the testing tools available for Android and mocking their dependencies >>> and found it to be lacking I defer to their judgement. Finally, good code >>> should have firewalls between system services and logic anyway so there >>> will be a lot of code that currently has dependencies on Android APIs that >>> won't in the future. >>> >> >> We would also like to eventually automate some integration tests, and >> "Java sync SDK" would be great for that. Android sync SDK would then use >> Java sync SDK and have only limited test set for integration/system tests. >> > > currently we don't have the need for that. > However, let's assume in the (near) future, there will be "cloud-apps", > powered by a modern java-stack (e.g. vertx). > The generic Java-SDK does not help you much here, since that's a > completely different platform (e.g. rxjava etc) > > -M > > >> >> >> On Tue, Aug 29, 2017 at 2:31 PM, Summers Pittman >> wrote: >> >>> >>> >>> On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel >>> wrote: >>> >>>> Hi, >>>> >>>> for those who don't know Dynamic SDK Team is now working on decoupling >>>> FH Sync SDK from fh-android-sdk. >>>> >>>> But not everyone probably know how is it dependent on rest of the SDK. >>>> I have few points from my little digging into it: >>>> 1) Good news is that there it's very little dependency on rest of the >>>> sdk. >>>> FH, FHActRequest, FHActCallback- for calling cloud service, basically >>>> only one method is used >>>> FHLog - for logging, wrapper for Android Log >>>> >>>> 2) Most difficult part would be to replace remote calls, but it's still >>>> quite easy. >>>> *For discussion: *Should we use *OkHttp* >>>> http client or more high level >>>> library like *Retrofit *? Or even >>>> use plain Java HttpsURLConnection or something else?? >>>> >>>> >>> OKHttp because I think we will get a lot more milage out of that level >>> of abstraction and the API is better (IMHO) and HttpsURLConnection. >>> Retrofit's use cases are very tied to RESTful APIs and I'm not sure that >>> RESTful is the future of sync. >>> >>> >>>> 3) Determining URL to cloud app after decoupling. *@wtrocki* How was >>>> this done in JS Sync SDK? >>>> >>>> 4) QE would like to have most functionality written platform >>>> independent (not dependent on Android SDK). >>>> Why to do that? We can have most tests running without emulator. This >>>> would result in much quicker and more stable execution. It's especially >>>> important when running tests on Circle CI, Jenkins or elsewhere. >>>> How to do that? >>>> We can have HTTP calls, logger and filesystem access written against >>>> interfaces. Then it can be implemented in Android or pure Java separately. >>>> Like this - https://github.com/feedhenry/f >>>> h-android-sdk/pull/107/commits/ae2c... >>>> >>>> >>> >>> >> -1 (ish). I agree with the sentament and some of the conclusions, but >>> this is an Android SDK and going out of our way to make it NOT an Android >>> SDK is a waste of time IMHO. Furthermore, Google has support for this >>> exact use case in their testing docs (https://developer.android.com >>> /training/testing/unit-testing/local-unit-tests.html#mocking >>> -dependencies). >>> >>> >> There are a few caveats to my -1 though. First if we want to make a >>> JavaSDK for use with desktop or server to server applications then you have >>> my interest and we should investigate that route. Second, if QE has looked >>> at the testing tools available for Android and mocking their dependencies >>> and found it to be lacking I defer to their judgement. Finally, good code >>> should have firewalls between system services and logic anyway so there >>> will be a lot of code that currently has dependencies on Android APIs that >>> won't in the future. >>> >>> >> >>> >>>> This would also serve as PoC of proper design for other future SDKs for >>>> 5.x/mobile.next. >>>> >>>> Thanks for your suggestions. >>>> >>>> -- >>>> >>>> VOJT?CH S?ZEL >>>> >>>> SENIOR QUALITY ENGINEER, MOBILE QE >>>> >>>> Red Hat >>>> >>>> >>>> >>>> Remote Czech Republic >>>> >>>> vsazel at redhat.com IM: vsazel >>>> >>>> >>> >>> >> >> >> -- >> Oleg Matskiv >> Associate Quality Engineer >> Red Hat Mobile Application Platform >> omatskiv at redhat.com >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Aug 30 12:55:38 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 30 Aug 2017 14:55:38 +0200 Subject: [feedhenry-dev] Sync decoupling from fh-android-sdk In-Reply-To: References: Message-ID: On Wed, Aug 30, 2017 at 1:57 PM, Wojciech Trocki wrote: > Really good points. I can create PR for IOS and Android to extend this > conversation to some example implementation. > The major problem I see is how we going to include sync into existing SDK. > I am all for a modular arch. That's what we did in AeroGear SDKs as well. All features were small libs/JARs > > For Android Sync will need to have their own network implementation and > use adapter pattern for elements expected by SDK (FHActCallback etc.) > IOS itself should be easier as we can use same network library and sdk can > just include sync as lib itself. > > Regards > Wojtek T. > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > On Tue, Aug 29, 2017 at 4:04 PM, Matthias Wessendorf > wrote: > >> >> >> On Tue, Aug 29, 2017 at 2:54 PM, Oleh Mackiv wrote: >> >>> -1 (ish). I agree with the sentament and some of the conclusions, but >>>> this is an Android SDK and going out of our way to make it NOT an Android >>>> SDK is a waste of time IMHO. Furthermore, Google has support for this >>>> exact use case in their testing docs (https://developer.android.com >>>> /training/testing/unit-testing/local-unit-tests.html#mocking >>>> -dependencies). >>>> >>> There are a few caveats to my -1 though. First if we want to make a >>>> JavaSDK for use with desktop or server to server applications then you have >>>> my interest and we should investigate that route. Second, if QE has looked >>>> at the testing tools available for Android and mocking their dependencies >>>> and found it to be lacking I defer to their judgement. Finally, good code >>>> should have firewalls between system services and logic anyway so there >>>> will be a lot of code that currently has dependencies on Android APIs that >>>> won't in the future. >>>> >>> >>> We would also like to eventually automate some integration tests, and >>> "Java sync SDK" would be great for that. Android sync SDK would then use >>> Java sync SDK and have only limited test set for integration/system tests. >>> >> >> currently we don't have the need for that. >> However, let's assume in the (near) future, there will be "cloud-apps", >> powered by a modern java-stack (e.g. vertx). >> The generic Java-SDK does not help you much here, since that's a >> completely different platform (e.g. rxjava etc) >> >> -M >> >> >>> >>> >>> On Tue, Aug 29, 2017 at 2:31 PM, Summers Pittman >>> wrote: >>> >>>> >>>> >>>> On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> for those who don't know Dynamic SDK Team is now working on decoupling >>>>> FH Sync SDK from fh-android-sdk. >>>>> >>>>> But not everyone probably know how is it dependent on rest of the SDK. >>>>> I have few points from my little digging into it: >>>>> 1) Good news is that there it's very little dependency on rest of the >>>>> sdk. >>>>> FH, FHActRequest, FHActCallback- for calling cloud service, basically >>>>> only one method is used >>>>> FHLog - for logging, wrapper for Android Log >>>>> >>>>> 2) Most difficult part would be to replace remote calls, but it's >>>>> still quite easy. >>>>> *For discussion: *Should we use *OkHttp* >>>>> http client or more high level >>>>> library like *Retrofit *? Or even >>>>> use plain Java HttpsURLConnection or something else?? >>>>> >>>>> >>>> OKHttp because I think we will get a lot more milage out of that level >>>> of abstraction and the API is better (IMHO) and HttpsURLConnection. >>>> Retrofit's use cases are very tied to RESTful APIs and I'm not sure that >>>> RESTful is the future of sync. >>>> >>>> >>>>> 3) Determining URL to cloud app after decoupling. *@wtrocki* How was >>>>> this done in JS Sync SDK? >>>>> >>>>> 4) QE would like to have most functionality written platform >>>>> independent (not dependent on Android SDK). >>>>> Why to do that? We can have most tests running without emulator. This >>>>> would result in much quicker and more stable execution. It's especially >>>>> important when running tests on Circle CI, Jenkins or elsewhere. >>>>> How to do that? >>>>> We can have HTTP calls, logger and filesystem access written against >>>>> interfaces. Then it can be implemented in Android or pure Java separately. >>>>> Like this - https://github.com/feedhenry/f >>>>> h-android-sdk/pull/107/commits/ae2c... >>>>> >>>>> >>>> >>>> >>> -1 (ish). I agree with the sentament and some of the conclusions, but >>>> this is an Android SDK and going out of our way to make it NOT an Android >>>> SDK is a waste of time IMHO. Furthermore, Google has support for this >>>> exact use case in their testing docs (https://developer.android.com >>>> /training/testing/unit-testing/local-unit-tests.html#mocking >>>> -dependencies). >>>> >>>> >>> There are a few caveats to my -1 though. First if we want to make a >>>> JavaSDK for use with desktop or server to server applications then you have >>>> my interest and we should investigate that route. Second, if QE has looked >>>> at the testing tools available for Android and mocking their dependencies >>>> and found it to be lacking I defer to their judgement. Finally, good code >>>> should have firewalls between system services and logic anyway so there >>>> will be a lot of code that currently has dependencies on Android APIs that >>>> won't in the future. >>>> >>>> >>> >>>> >>>>> This would also serve as PoC of proper design for other future SDKs >>>>> for 5.x/mobile.next. >>>>> >>>>> Thanks for your suggestions. >>>>> >>>>> -- >>>>> >>>>> VOJT?CH S?ZEL >>>>> >>>>> SENIOR QUALITY ENGINEER, MOBILE QE >>>>> >>>>> Red Hat >>>>> >>>>> >>>>> >>>>> Remote Czech Republic >>>>> >>>>> vsazel at redhat.com IM: vsazel >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> Oleg Matskiv >>> Associate Quality Engineer >>> Red Hat Mobile Application Platform >>> omatskiv at redhat.com >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Wed Aug 30 13:14:17 2017 From: supittma at redhat.com (Summers Pittman) Date: Wed, 30 Aug 2017 09:14:17 -0400 Subject: [feedhenry-dev] Authentication in Mobile.Next In-Reply-To: References: Message-ID: We've made some Spikes to schedule and work out in the future based on this thread and the meeting. Hat tip to Craig's impromptu demo :) https://issues.jboss.org/browse/FH-3993 On Mon, Aug 28, 2017 at 11:43 AM, Wei Li wrote: > > > On Fri, Aug 25, 2017 at 4:47 PM, Wojciech Trocki > wrote: > >> Hi Wei >> >> I'm not really 'external' developer, but I'm heavily invested in that >> area so wanted to share my thoughts. >> >> On Fri, Aug 25, 2017 at 3:33 PM, Wei Li wrote: >> >>> Hi FeedHenry developers, >>> >>> As you may have heard, we are planning on delivering a few >>> mobile-focused services in Mobile.Next project. One of the services we are >>> looking at is authentication. >>> >>> As a start, we first would like to kick off some discussions around >>> requirements & expectations of this service within the community. More >>> specifically, we are looking for some answers to the following questions: >>> >>> * What is the biggest pain point you currently have in terms of user >>> authentication when develop mobile applications? >>> >> >> *From what I have seen so far most of the problems I encountered can be >> assigned to two categories:* >> >> - Legacy, custom auth in the cloud. Difficult to integrate authentication >> with user sources. >> - SDK's are build with assumption that some particular security solution >> (FH_AUTH_... headers e.g.) is being used (Lack of choices on the client) >> > > Looks like these are about using the existing auth function of the > platform. Sorry I didn't make it clear but what I am looking for here is > not about using FH.auth, but in general - e.g. What are the pain > points/problems when you need to implement user authentication in a mobile > application (that may not use FH.auth/RHMAP)? > > FH.Auth is deprecated and we are looking at a new implementation for > Mobile.Next. > > >> >> >>> * What features/functions around authentication you should like to see >>> in Mobile.Next, both client and cloud side? >>> >> >> *RHMAP specific **functionalities**: * >> >> *- Authentication detached from SDK's * >> For example by creating auth service (keycloak). >> Lightweight aproach (for example using JWT in node.js server) should >> still be possible - let's avoid hard dependency to security service. >> >> *- Pluggable auth* >> Feedhenry libraries should have clear and documented path that will >> properly explain how authentication and authorization can be added. >> >> *- Local setup (development)* >> IMHO We should provide options to work when this service is not >> provisioned (development, local setup etc.) >> >> *Keycloak specific functionalities (little bit outside auth area)* >> >> *- Preconfigured realm with "suggested security options"* >> Create realms that will come with the best security practices. >> This realms, may be used as template for creating some specific app type >> (mobile, website etc.) >> > > +1. I think for a non-security expert, Keycloak is not really that easy to > use. We need to figure out something to make it as easy as possible to > setup, or "just work". Creating/configuring sample realms sounds like a > good approach to explore. > > >> >> *- Automatic creation of client when deploying new template (depending on >> type)* >> We can associate client with mobile/website template and create separate >> one if needed. >> This will reduce amount of boilerplate and will allow us to support >> "default" authentication. >> It will work nice with demos and simplify overall getting started >> experience. >> >> *- Templates that promote best security patterns (PIN, secure file >> storage, encrypted sync and work with default realm)* >> This may not be related to auth, but I think it's best to have template >> that will include "best security practices" and can be used as base for >> projects. >> Everything to improve getting started experience with Keycloak and RHMAP. >> > > Yes, this is the aim of the mobile security project we are working on at > the moment. > > >> >> *- Supporting keycloak customization (if possible)* >> Users should be able to provide custom login page (probably requires s2i >> build), change configuration, add user federations without breaking >> RHMAP integration. >> IMHO we should allow developers to configure keycloak as they wish >> without breaking other services and that may be the challenge. >> >> >> >>> * If you have used Keycloak before, what is your thoughts on integration >>> with it in mobile applications? >>> >> >> >> Keycloak usability depends on the platform (website, cordova, android >> etc.). >> Some of the functionalities may not be available on the mobile etc. >> >> Keycloak auth is really specific as most of their documentation and demos >> focus on customized login page (which is website) >> >> The biggest pain point with keycloak IMHO is that it needs to be >> strongly integrated with your app. >> For example integrated keycloak is adding lots of random data into URL >> which breaks most of the javascript frameworks that use hash routers. >> Users lose control over the login page etc. When using token based >> aproach this problems will disappear, but this may be difficult for >> beginners. >> >> Another pain point is that to make some modifications around user >> federations, login page and themes require physical changes in container - >> like dropping jar. >> It's not that this will hit our customers but it may be painful to >> orchestrate to our service architecture. >> >> Another problem you may hit is that keycloak seems to be more centralized >> single sign on solution - where companies and corporations have single >> instance of it >> to deal with all auth problems in organization. If we start spinning >> multiple services we need to think about granularity and duplication of >> user data issues that may appear. >> You probably have all of this sorted, but wanted to mention that just in >> case. >> >> IMHO the biggest challenge here is to get something generic as it will >> mean that some particular choices will need to be made for developers. >> Keycloak is pretty good and generic framework on his own that can be >> setup and configured in short amount of time. >> Most of the work required to setup keycloak will be related with actual >> configuration (realms, groups etc.) that is hard to generalize. >> >> I think that I might be missing the main point here: >> *What will be the end user value or set of technical problems team want >> to resolve by having Keycloak service over the standard keycloak template >> deployed to OpenShift?* >> > > It probably will be the same Keycloak, but optimised for mobile > applications. In my view, the ideal scenario would be that a developer > enables the service, no configuration required, just download the > configuration file, add the client side library into the mobile application > and done. For all the other services, the request authentications are > handled automatically. > > There might be some other configurations that they can change, but those > should be well documented, and the users don't need to know Keycloak if > they don't want to. > > >> *What kind of level of configuration and automation team want to provide >> (Should user create their realms etc.?)* >> > > In my view, as much as we can to the point where it will just work by > default. > > >> *Do we plan to enable security for our templates outside the box?* >> > > Are we still talking about client templates? There will be some templates > dedicated to demonstrate the best security practices, and hopefully all the > templates will have some degree of security elements in them. > > >> >> >>> * Anything else around authentication? >>> >> >> Do we plan to do Authorization? >> >> > > I would say yes, but that's another discussion. > > >> >>> The answers to those questions will help us make sure we deliver >>> something that will solve the problems you are facing day to day. >>> >>> We look forward to your answers and thank you in advance. >>> >>> Regards, >>> >>> -- >>> >>> WEI LI >>> >>> SENIOR SOFTWARE ENGINEER >>> >>> Red Hat Mobile >>> >>> weil at redhat.com M: +353862393272 >>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acarmona at redhat.com Thu Aug 31 14:24:49 2017 From: acarmona at redhat.com (Andrea Carmona) Date: 31 Aug 2017 10:24:49 -0400 Subject: [feedhenry-dev] Upcoming Red Hat DevNation Live Tech Talk: Big Data in Action with Infispan Message-ID: <28b026b19b184f439806fb28daea12f5@1795> Read the online version . "Red Hat" Hi RedHat, Join the Red Hat DevNation for an upcoming live session on September 7, 2017, as Galder Zamarreno presents Big Data In Action with Infispan. Dealing with real-time, in-memory, streaming data is a unique challenge and with the advent of the smartphone and IoT (trillions of internet connected devices), we are witnessing an exponential growth in data at scale. Building data layers that can satisfy these requirements can be challenging, but with the help of Infinispan, an in-memory data grid, you can take advantage of state of the art distributed data processing capabilities to tackle these challenges. From classic or full-text queries, to Spark/Hadoop integrations via distributed Java Streams, these wide ranging data processing capabilities make Infinispan the perfect choice for the Big Data era. In this session, we will identify critical patterns and principles that will help you achieve greater scale and response speed. On top of that, you will witness how Infinispan follows these patterns and principles to tackle a big data situation via a live coding demonstration. Register Now For more information and to view the schedule, click here . We hope you join us! Regards, Andrea Carmona The Red Hat Developer Program __________________________________________________________________ [f1]Contact our sales team [f2]Manage your newsletter preferences [f3]Read our privacy policy [f4]Unsubscribe from all Red Hat email "Red Hat" and the "Shadowman" logo are trademarks or registered trademarks of Red Hat, Inc. Linux is a registered trademark of Linus Torvalds. ? 2016 Red Hat, Inc. All rights reserved. 100 East Davie Street Raleigh, NC 27601 [f5][twitter.png] [f6][facebook.png] [f7][redhat.png] References f1. http://www.redhat.com/apps/webform.html?event_type=contact_sales&eid=21 f2. https://www.redhat.com/wapps/ugc/email-subscriptions.html?elqc=241&elq=28b026b19b184f439806fb28daea12f5 f3. http://www.redhat.com/legal/privacy_statement.html f4. https://www.redhat.com/wapps/ugc/master-unsubscribe.html?elqc=241&elq=28b026b19b184f439806fb28daea12f5 f5. http://www.twitter.com/redhatnews f6. http://www.facebook.com/pages/Red-Hat/11218770329 f7. http://www.redhat.com/community/?sc_cid=70160000000I9TnAAK -------------- next part -------------- An HTML attachment was scrubbed... URL: