AeroGear Crypto Java 0.1.2 released
by Bruno Oliveira
Good morning, just to let you know we released today the bits for digital signatures and some bug fixes.
Have a happy new year sweet hearts.
--
abstractj
2 years
[help needed] AG Xamarin multiplatform service module problem
by Vojtech Sazel
Hi,
we encountered a problem with Aiden and Massimo with the underlying
architecture of the multiplatform project in Xamarin.
We need to have Auth service module accessible from application. But module
has some platform specific implementations we need to get.
1) Suppose we have some class Auth implementing IServiceModule. We would
have it implemented only using platform-independent. So we can simply do
MobileCore.Instance.GetInstance<Auth>()
2) But now we need to have some platform specific stuff done in the module,
so we create AuthAndroid and AuthIOS extending Auth (which is now abstract)
in platform specific projects.
In ordinary pure Android (or iOS respectively) app we can do:
MobileCore.Instance.GetInstance<AuthAndroid>()
3) But we can't do that with Xamarin.Forms app where stuff is in platform
independent project.
We can utilize DependencyService in Xamarin.Forms app project or create
separate Xamarin.Forms project with Auth, but it seems that code won't be
very pretty in this case.
What can we do to solve this problem?
I think we can debate it further after todays ST1 standup.
--
VOJTĚCH SÁZEL
SENIOR SOFTWARE ENGINEER, RED HAT MOBILE
Red Hat
<https://www.redhat.com/>
Remote Czech Republic
vsazel(a)redhat.com IM: vsazel
<https://red.ht/sig>
6 years, 1 month
aerogear stickers for red hat summit
by Tuomas Kuosmanen
Hello,
I was requested to do some stickers for AeroGear for the upcoming Red Hat
Summit conference to give away, so I figured I'd share the design for
comments.
It would be a die-cut sticker approximately 10cm wide, with the white
outline on the cutout to make it stand out from the background (works on
dark laptop lids).
Best wishes,
Tuomas
6 years, 1 month
Xamarin AG SDK project structure
by Vojtech Sazel
Hi,
I merged Core PR. With it it comes unification of project strucure.
We have
- Core
- Core.Platform.Android/
- Core.Platform.iOS/
- Core.Platform.NuGet/
- Core.Platform.Shared/
- Core.Tests/
- Auth
- Auth
- Auth.Tests
- Auth.Platform.Android
- Auth.Platform.iOS
- Example
-
- Example/
- Example.Android/
- Example.iOS/
- Documentation
--
VOJTĚCH SÁZEL
SENIOR SOFTWARE ENGINEER, RED HAT MOBILE
Red Hat
<https://www.redhat.com/>
Remote Czech Republic
vsazel(a)redhat.com IM: vsazel
<https://red.ht/sig>
6 years, 1 month
aerogear.org refresh work
by Tuomas Kuosmanen
Hello.
I am a designer at the Open Source and Standards team at Red Hat. We help
communities with various things.
I have been working on the aerogear website refresh which is viewable here
for now: https://tigert-work.github.io/
It's a github pages site that follows this repo:
https://github.com/tigert-work/tigert-work.github.io
The idea behind the change comes from the effort to split documentation
into a separate site that focuses on being developer friendly and usable,
and the main aerogear.org would have more focus on showcase of the project.
The plan is to move the repo over to aerogear github organization
eventually, but right now I am requesting help with the content, because I
do not have much hands-on experience in AeroGear myself. My brief
discussion on IRC also revealed that some of that content I took from the
old site as a starting point is indeed old and no longer true.
What we have so far:
Front page:
- The two columns' wording is rough, but it tries to explain that we
have a toolkit with different modules for mobile development with OpenShift
/ Kubernetes as the service platform.
- It also showcases the three featured modules and links to per-module
pages that will explain a bit more of each.
Get Started:
- Getting Started is something I need help with. The process as far as I
understand, involves your own private openshift instance and probably more
things I am not aware of. My understanding is that the user will spin up
the service catalog and start the aerogear service, then install the sdk
and build an example application (probably push notifications) that you get
up and running. There then needs to be a link for more examples covering
the other modules on the new documentation site. This would be something we
should try to make as easy as possible to get started, but the requirement
of your own openshift kind of makes it quite a different scale than just
installing a plugin on your android sdk and building an example app. Ideas
are welcome :-)
Documentation:
- This link is currently broken as new docs are being split into
docs.aerogear.org that does not yet exist.
Community:
- This is from the current site, and it is probably OK apart from the
"Contributing to AeroGear" links that needs to be rewritten and link-fixed
once the new docs are in place.
Module pages: These are under construction as well, whatever content there
is is mostly from the existing site.
Any help with the content would be appreciated, both structural "flow" and
spotting inaccuracies or problems. You can file github issues on the
repository for example.
Thanks a lot for any time and effort you can spare on this.
Tuomas
6 years, 1 month
Make debugging compatibility issues easier
by Paul Wright
Hi,
I've been thinking about some simple debugging procedures, seems like
we'll be asking users to:
1. Reload config json for mobile app (cos something might have changed
on OpenShift side)
2. Check a Compatibility Matrix <not%20there> to make sure that your
sdks and services all match up
That second step seems to be a non-optimal user experience, could we add
compatibility information to config json?
This would mean the user would not have to leave their IDE to check out
a compatibility issue.
How might it work?
Each update to a service could include the following info:
* compatibleWith
* incompatibleWith
and as part of updating a service, include known compatibility, for
example with Keycloak Service v2.3.1 you might have
"androidSDKCompatibleWith":[ "2.x.x", "3.x.x" ],
"androidSDKIncompatibleWith":[ "2.0.x" ]
The user can then check the SDK version and take action as required,
WDYT?
Paul
--
Paul Wright
Mobile Docs (github: finp)
6 years, 1 month
Introducing Antora for publishing docs
by Paul Wright
Hi
Up to now, I've been using asciibinder [1] to preview docs, but Dan
Allen (of asciidoctor fame) has released Antora [2], which addresses our
use case better, and I'd like to switch to using that.
Specifically, Antora is designed to work with:
* remote code repos where docs is written along side code
* multiple component versions (automatically provides menus to switch
between versions)
We were trying to script around asciibinder to allow for those issues
(remember asciibinder was written for OpenShift, a single product with
multiple flavors, rather than a set of versioned services), however I
think we can get further faster with Antora .
This won't affect the way you author adoc files (in fact it should make
it easier), we'll just need to include a structure in each docs directory.
If you look at the Antora docs [2] you can see the system in action, the
menu at the bottom left allows you switch between versions (currently
only 1.0 is available), and a component (Antora Default UI). You'll also
see that there's a link to 'Edit this Page' which will direct you to the
correct repo and branch as required.
There are a lot of other advantages [3], but I've outlined the main
ones, and created a rough rendering of what it means for AeroGear [4]
Let me know of any objections,
thanks,
Paul
[1] http://asciibinder.org/
[2] https://docs.antora.org
[3] https://antora.org/
[4]
https://drive.google.com/file/d/1l4AJGKSLI2e7vy9emIkVNTojf-C1waFM/view?us...
--
Paul Wright
Mobile Docs (github: finp)
6 years, 2 months
Make MobileCore Init automatically called in Android SDK
by Daniel Passos
Hi,
Revisiting some Google and Firebase stuff Summers and I realized the
Firebase Android SDK doesn’t need we do any init to the lib starts/be
configured.
TL;DR what Firebase does is uses a Content Provide[1] (not really created
for this) as a trick to initialize the lib before the app starts
Why Content provider?
Because it has access to the applicationContext[2] and is called *before*
all other Android kinds of stuff in the Android lifecycle (including
Application)
I’d like to do the same for our Android SDK and initialize the lib using
the same trick so we can provide a MobileCore.getInstance() already
configured with all the things the developer needs (Logger, HttpLayer,
Mobile Services info, etc…) without need to create an application class or
call MobileCore.init(context) anywhere and kill all static methods we have
today in MobileCore
It will also allow us to send the default metrics before the Android
lifecycle starts the app and have some controls (when need) to know when
the app is in background and foreground, listeners possible crashes and
other things without the developer needs to call/configure anything.
PS: This is will probably be the first step to kill the responsibility to
the MobileCore instantiate the Service Modules[3]
Any thoughts?
[1]
https://developer.android.com/guide/topics/providers/content-providers.html
[2]
https://developer.android.com/reference/android/content/ContentProvider.h...
)
[3] https://issues.jboss.org/browse/AGDROID-796
--
-- Passos
6 years, 2 months
