[Pipe] Wrapped Response
by Tiago Resende
Hi guys, My name is Tiago, I am an old Daniel Passos's student from Brazil.
I'm new here and have a lot of noob questions, so, take it easy and forgive
my english.
I am trying to integrate AG for Android to a WCF Service on .Net C#, but
all service responses are configured as Wrapped, so AG isn't working
properly.
I just wanna know... Should I create Wrapped objects for every endpoint, or
is there another method to do it, some work around?
Thanks everyone.
--
*Tiago de Carvalho Resende*
Desenvolvedor
"O importante não é saber fazer,
é saber de onde copiar."
por Bernardo Esbérard
10 years, 1 month
[UPS-Console] Showing Registration Code Snippets
by Sebastien Blanc
Hi,
I've started to work on AGPUSH-550
<https://issues.jboss.org/browse/AGPUSH-550> where
the idea is to generate Device Registration code Snippets that the user can
copy/paste into his client application.
The flow is quite simple : he chooses a Variant, then click a link on the
right that brings you to the Snippets page.
Since the console knows the type of the selected variant, the appropriate
snippet is generated ... Yes "generated" , that means it's not a static
code snippet but it's actually filled with the needed info : UPS Server
URL, Variant ID, Variant Secret, SenderId (for Android).
For each code snippet, there also the Cordova version for it. So, if you
choose an Android variant for instance you will have :
[image: Inline image 1]
And as you can see, there is also a link to cordova :
[image: Inline image 2]
This is still work in progress, needs polishing etc ... But once we got
this, it will be really easy for a new user to get started. All the
variants type are covered : iOS, Android and SPS
Oh, want to test it live ? Give it a try here :
https://newpush-sblanc.rhcloud.com/ (admin / 123)
I will probably PR that very soon, in the same time you can check this
branch
https://github.com/sebastienblanc/aerogear-unified-push-server-admin-ui/t...
if
you want to play with it locally.
See you !
Sebi
10 years, 1 month
Let's change the AeroGear Twitter account handle
by Hylke Bons
"@AeroGears" can cause confusion about what the project name really is.
Options to fix:
- Ask the owner of @AeroGear if he or she want to give up the handle
- Change the handle to "@AeroGearTeam" or "@AeroGearProject", or
something else
Thoughts?
Hylke
10 years, 1 month
Re: [aerogear-dev] Modularizing the Android Library
by Summers Pittman
On Wed 05 Mar 2014 10:58:45 AM EST, Matthias Wessendorf wrote:
>
>
>
> On Wed, Mar 5, 2014 at 4:35 PM, Summers Pittman <supittma(a)redhat.com
> <mailto:supittma@redhat.com>> wrote:
>
> On Wed 05 Mar 2014 10:32:49 AM EST, Matthias Wessendorf wrote:
>
>
>
>
> On Wed, Mar 5, 2014 at 4:29 PM, Daniel Passos
> <daniel(a)passos.me <mailto:daniel@passos.me>
> <mailto:daniel@passos.me <mailto:daniel@passos.me>>> wrote:
>
> I'd like add push in lib name
>
> aerogear-android-push (for core)
> aerogear-android-push-gcm
> aerogear-android-push-mqtt
>
>
> I still think that mqtt is more messaging, instead of push :-)
>
> Well right now it would be "push" because we don't support
> bidirectional communication. MQTT is just the transport.
>
> We SHOULD investigate messaging soon since GCM supports it.
>
>
> and that's different from push (think APNs / SimplePush), which is
> what we support on the UnifiedPush Server.
>
Right. mqtt and friends were just examples of things we had talked
about.
However messaging for the project may be something we look at one day.
>
> doing messaging, via GCM, is fine but something different. There the
> underlying technology (e.g. MQTT vs. GCM) is really just a transport,
> like:
>
> -messaging-gcm
> -messaging-mqtt
> -messaging-stomp
>
>
> -M
>
>
>
>
>
> -- Passos
>
>
>
> On Wed, Mar 5, 2014 at 11:42 AM, Matthias Wessendorf
> <matzew(a)apache.org <mailto:matzew@apache.org>
> <mailto:matzew@apache.org <mailto:matzew@apache.org>>> wrote:
>
>
>
>
> On Wed, Mar 5, 2014 at 3:41 PM, Lucas Holmquist
> <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>
> <mailto:lholmqui@redhat.com <mailto:lholmqui@redhat.com>>> wrote:
>
>
> On Mar 5, 2014, at 9:33 AM, Matthias Wessendorf
> <matzew(a)apache.org <mailto:matzew@apache.org>
> <mailto:matzew@apache.org <mailto:matzew@apache.org>>> wrote:
>
>
>
>
> On Wed, Mar 5, 2014 at 3:15 PM, Summers Pittman
> <supittma(a)redhat.com
> <mailto:supittma@redhat.com> <mailto:supittma@redhat.com
> <mailto:supittma@redhat.com>>> wrote:
>
> Earlier in development (pre passos) making the
> Android SDK into modules
> was not a concern (in fact it was an
> anti-concern).
>
> Now, however, we have a much more complete
> project
> and it is time to
> have that discussion.
>
> Right now we have two BIG questions:
>
> 1) Do we want to break out interfaces and
> implementation?
>
> If we do this then we could reuse a lot of
> code to
> make a aerogear-java
> as well.
>
> 2) How granular do we want our modules?
>
> IE If we break out push into
> aerogear-android-push
> would that include
> GCM, SimplePush, MQTT, etc in one package
> or would it
> look like
>
>
> android-gcm
> android-simplepush
> android-mqtt
>
>
> +1 to those names, and i'm sure you mean
> aerogear-* :)
>
>
> yep ;-)
>
>
>
>
>
> aerogear-android-push-core,
> aerogear-android-push-mqtt etc.
>
> Thoughts?
>
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
>
>
> _________________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.__jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
>
> https://lists.jboss.org/__mailman/listinfo/aerogear-dev
> <https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>
>
>
>
> --
> Matthias Wessendorf
>
> blog:
> http://matthiaswessendorf.__wordpress.com/
> <http://matthiaswessendorf.wordpress.com/>
> sessions:
> http://www.slideshare.net/__mwessendorf
> <http://www.slideshare.net/mwessendorf>
> twitter: http://twitter.com/mwessendorf
> _________________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.__jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> https://lists.jboss.org/__mailman/listinfo/aerogear-dev
> <https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>
>
>
> _________________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.__jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
>
> https://lists.jboss.org/__mailman/listinfo/aerogear-dev
> <https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.__wordpress.com/
> <http://matthiaswessendorf.wordpress.com/>
> sessions: http://www.slideshare.net/__mwessendorf
> <http://www.slideshare.net/mwessendorf>
> twitter: http://twitter.com/mwessendorf
>
> _________________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.__jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
>
> https://lists.jboss.org/__mailman/listinfo/aerogear-dev
> <https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>
>
>
> _________________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.__jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
>
> https://lists.jboss.org/__mailman/listinfo/aerogear-dev
> <https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.__wordpress.com/
> <http://matthiaswessendorf.wordpress.com/>
> sessions: http://www.slideshare.net/__mwessendorf
> <http://www.slideshare.net/mwessendorf>
> twitter: http://twitter.com/mwessendorf
>
>
> _________________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/__mailman/listinfo/aerogear-dev
> <https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>
>
>
>
> --
> Summers Pittman
>
> Phone:404 941 4698
> Java is my crack.
>
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
10 years, 1 month
Re: [aerogear-dev] Android Push: 3G /WiFi
by Torben
Hello Matthias,
Hello Erik,
thanks for your fast reply!
> That's weird :) Your device is listed on the unifiedpush admin console,
> right ?
> I guess, otherwise you would also not receive messages, when on 3G :)
>
> Kinda odd, but not sure... You phone should be able to receive messages on
> local wifi as well.
> All it needs: a working internet connection (internally Google's GCM has a
> persistent connection to your phone)
Yes, all devices are listed in the admin console.
It's really wired, I have read about difficulties with some routers
cutting network connections on the GCM Google group - and I noticed a
difference between office and home network connection right now.
I will debug more into this on monday when I am back in the office..
>
> The exception below is no harm at all - it's an open issue at the APNs lib
> we use internally:
>
Thanks for the info! So I don't have to go into this..
Great work, excited to get more into aerogear and the openshift cartridge!
This is a nice alternative to other proprietary Push Service Providers..
Kind regards,
Torben
10 years, 1 month
Comparing sync in Android vs other platforms
by Summers Pittman
For the DevNexus Android app[1] I used Android native sync APIs[2] + the
sync strawman[3] I put out back in December. It worked surprisingly
well with a few caveats.
First a background on how Android sync works.
Android sync is handled by three components: a SyncAdapter, a
ContentProvider, and a Authenticator.
The Sync Adapter performs as sync and returns a status object. The
SyncAdapter is called from, managed by, etc the Android platform. It
provides an onPerformSync that the developer implements. In the
application the developer sends signals to Android which control
scheduling sync (periodic, immediate, event based etc). Also Android
will put in the "Account" settings page a control for the SyncAdapter.
In this case the SQLSynchronizer I proposed was used to implement this
method.
The ContentProvider is responsible for CRUD operations on your data,
exposing your data to other apps on the device, and notifying the system
if data changes. This is managed by Android as well. In this case the
CP was backed by a SQLStore.
Finally the Android Authenticator is responsible for establishing and
maintaining authentication with remote services. If the user is not
signed in, or if fetching an auth token fails, the Authenticator will be
called by Android to provide a Activity which can be used to refresh the
users account. In this case I used two custom AuthenticationModules.
One handled SSO with Google and the other handled keeping the cookie up
to date. Both communicated with the DevNexus server to keep all of the
tokens fresh.
Overall, Android provides a very VERY slick (but very very complicated)
way of managing sync AND keeping the sync state visible to the user. If
you use Androids APIs then the OS handles things like Authentication
errors, intermittent connectivity, etc while providing configuration for
a variety of sync use cases (UI event based, polling, data listening, etc).
I tried looking up what options are available in JS land but the closest
I came to was a FFOS blurb about it is a TODO item and isn't a W3C
proposal or anything yet.
I tried looking at iOS but the docs made my eyes cross.
So what does the PLATFORM support look like in these environments?
----
[1]https://github.com/secondsun/devnexusAndroid
[2]http://developer.android.com/training/sync-adapters/index.html
[3]https://github.com/secondsun/aerogear-android/tree/sync_strawman/src/or...
10 years, 1 month
Compose Push UI - draft (was: Re: UnifiedPush: Sending notifications from the AdminUI)
by Matthias Wessendorf
Hello Sebi,
that looks really nice!
Hylke can you take a look at the first version, from a UX persons view?
Thanks!
Matthias
On Tue, Feb 25, 2014 at 10:06 AM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
> Hi,
> I started to work on a new "Compose Message" page. The idea is that you
> can add criterias to your message , as you can see here on this screenshot
> :
> [image: compose2]
> I've also deployed a live version but *DICSLAIMER* this is just UI /
> Mockup work sending will not work for now :
> http://newpush-sblanc.rhcloud.com => Select an App and you will have a
> "Copomse Message" link on the next page.
>
> Feedback is welcome.
> Sebi
>
>
> On Mon, Feb 24, 2014 at 1:25 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
>
>>
>>
>>
>> On Mon, Feb 24, 2014 at 12:52 PM, Hylke Bons <hbons(a)redhat.com> wrote:
>>
>>> Sounds good.
>>> Let me know if you need any help with the mockup designs. ;)
>>>
>> Sure, I will ASAP submit a "raw" mockup on which you can work on.
>> What I would like is a dedicated page for the "Compose Push Message"
>> feature.
>>
>> We wil have a criteria section to choose to who we want to send the
>> message. I really like for instance how Jira do that like here
>> http://postimg.org/image/5ur2j9wh5/
>> In our case we could have the drop downs for : "Variants", "Device Type",
>> "Alias" and "Categories"
>> And then below w will have a free text area to send a custom value.
>>
>>
>>>
>>> Hylke
>>>
>>>
>>>
>>> On 23/02/2014 12:08, Sebastien Blanc wrote:
>>>
>>>
>>>
>>>
>>> On Sun, Feb 23, 2014 at 1:04 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>>>
>>>> Hi,
>>>>
>>>> over the weekend I spoke w/ a friend: His company is doing some
>>>> mobile (iOS/Android) apps which also support receiving push notifications.
>>>>
>>>> Two examples he told me. After receiving push notification:
>>>>
>>>> * One of their apps basically fetches the latest version of a CSV
>>>> file, stored on a public HTTP Server.
>>>>
>>>> * Another app is used to tell sales guys new brochure files (PDF) are
>>>> available on a protected resource of a webserver (which they _can_ than
>>>> download from w/in the app, if the like to)
>>>>
>>>> The company build a simple console (PHP) which allows them to send
>>>> new push messages, when ever their customers want to.
>>>>
>>>> I showed them our UnifiedPush Server and its usage via our AeroDoc
>>>> example (iOS / backend). They really liked the UnifiedPush Server.
>>>> Especially that it does store all the device metadata.
>>>>
>>>> But since a lot of their mobile apps don't have a backend
>>>> requirement, they would still have to use their own console (which than
>>>> connects to UPS) for submitting all the push messages they want.
>>>>
>>>>
>>>>
>>>> This brings me to [AGPUSH-38] and I really think we should implement
>>>> that feature. Not only for sending test messages! If our UnifiedPush Server
>>>> allows its users to simple send push messages to all of their mobile apps,
>>>> it would make the server even more attractive.
>>>>
>>>> I regret a bit that I was against [AGPUSH-38] in the beginning, I
>>>> guess that's due to my Java enterprise background, where you typically find
>>>> complex setups, and server talk to servers :-(
>>>>
>>>> Anyways, now I really think that the UPS has to have such a 'send
>>>> push' facility inside of the Admin UI :-) I believe that we could reach way
>>>> more potential users with something like that
>>>>
>>> +9001 and I already started thinking about this for a while. I will try
>>> to submit some mockups/POCs this week so we can discuss that and I have
>>> quickly a first working version on master.
>>>
>>>
>>>> Any thoughts?
>>>>
>>>>
>>>> Greetings,
>>>> Matthias
>>>>
>>>>
>>>> [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 1 month
