Cordova
by Erik Jan de Wit
Hi,
Now Cordova has it’s own jira project and therefore it’s own version number, but in github the plugins have their own repository. Would it make sense to move all the plugins into one central github repository and when making a release to release all of them?
Wdyt?
Erik Jan
9 years, 12 months
Unified Push responds with 404 if no installations exist for a variant
by Tadeas Kriz
Hey,
while aligning integration tests with 0.11.0, I’ve found a changed behaviour when requesting list of installations for a variant. Before the change, if I used wrong (non-existent) variant ID, I got 404 Not Found, and when I used existing variant ID, I got a response with an empty json array. That way I could easily say if the variant id was wrong or not. Now, I get 404 even when the variant ID is correct, but the variant has no installations. The old code: [1] and the new code: [2]
My question is, if this is by design? And if so, why doesn’t variant listing work the same way? From [3] I understand that it responds with an empty json array when there are no android variants for the given push application ID and with 404 if the push application ID is wrong. I just want to be sure before changing integration tests to expect the 404 instead of an empty json array.
Thanks
1 - https://github.com/aerogear/aerogear-unifiedpush-server/blob/2ecf73ea4e3b...
2 - https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs...
3 - https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs...
—
Tadeas Kriz
10 years
AG Push Console review
by Lukáš Fryč
Hey guys,
Viliam asked me to forward his review notes/remarks here:
Nice job, Viliam, I will incorporate your suggestions.
Btw the overall state of UX improvements is tracked here:
https://issues.jboss.org/browse/AGPUSH-671
Cheers,
~ Lukas
-------- Original Message --------Subject:AG Console review Date:Wed, 28
May 2014 15:01:19 +0200From:Viliam Rockai <vrockai(a)redhat.com> To:Matthias
Wessendorf <mwessend(a)redhat.com>, Lukas Fryc <lfryc(a)redhat.com> CC:Alexandre
Mendonca <amendonc(a)redhat.com>
Hi,
I went through the console code. Overall, it looks just fine. Previously
I thought I'll just put comments into the code and make a commit. Since
I found only a few issues, it's not worth it. So here is my list:
* The name of your angularjs module is "newadminApp". I think it should
be something like "agconsole".
* You're missing feedback for user on many places. If the error says
'Something went wrong...', it doesn't say much to a user. Even changing
it to denote the current operation would be better, something like
'Unable to create new application'. On most of the $resource.* methods
you're missing the feedback, too. For most of them the information about
success would be annoying, but maybe it could be interesting for user to
see errors like 'Unable to get the application list, check your
connection to the server...'. When my session to the console timed-out,
the operation I was trying to do (renaming of app) didn't do anything,
but I had no clue why.
* AFAIK it's considered a bad practice to use jQuery inside controllers.
You use only two $ functions: $.extend and $.ajax, which can be replaced
with angular.extend/angular.copy and the $resource service. If you can't
find a way how to do something without jQuery inside controller, maybe
creating of custom directive is the right solution, but this doesn't
seem to be the case.
* It seems that you're using several switch statements just to assign a
value based on input. This seems to be a good candidate for using a map.
* Notifications - they are inside ng-view pages. It looks fine and works
for your current purposes. But if you make some new page in the future,
which redirects you (i.e. creating a new entity, after submit, user is
redirected to entity list with newly created stuff), you may loose the
message. Another disadvantage of this is non-consistent L&F for feedback
messages. The advantage is, that you're not covering any content with
the message as LO does.
* In installation.html I see stuff like <col width="45%">. I think this
should be rewritten to use the bootstrap grid layout (classes like
col-md-12...).
* We use our custom directive lo-autofocus for the 1st input in modals.
Right after the modal pops-up, user has the focus on the first input and
pressing enter submits the modal.
* The last one is not a problem at all, I just don't feel right about
it :) You use $window.location.href instead $location.absUrl(). They
seem to do the same, but since you don't use any other $window stuff,
using $location makes more sense to me.
Btw, we were thinking about creating a dynamic creation of breadcrumbs,
too. But since we didn't want to have them fully dependent on the URL
(URLs could change for us in the future), we didn't do it. Are you sure
you want to make url and breadcrumbs to be linked this way?
Anyway, congrats, you did good job with the console and this review
helped me to get aware of some problems the LO console may have, too.
Viliam
10 years
Understanding AeroGear development
by jmanko
I'm trying to get a hold on how to start development with AeroGear. Is there
any tutorial on the actual HTML design (code, not visual editor). Are all
applications meant to be single-paged with multi-view DIVs? That's a lot of
unrelated content on the same page, and makes it messy when having to design
larger scaled apps.
Anything that walks through what's taking place in the kitchen-sink sample
HTML page would be great, and what the standard conventions are. Thank you
in advance.
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Understanding-AeroGear-developm...
Sent from the aerogear-dev mailing list archive at Nabble.com.
10 years
New Cordova (Push) release? (was: Re: [Mobile Push 1.0.0] Client SDKs for Android, Cordova and iOS)
by Matthias Wessendorf
Hello,
the latest Android libs are now on master - should we do another release,
this week ?
-Matthias
On Sun, May 25, 2014 at 1:40 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
> Awesome! Thanks for commenting, guys!
>
> @Cordova: Will test (and merge ;-)) on Monday
>
>
> On Fri, May 23, 2014 at 4:45 PM, Erik Jan de Wit <edewit(a)redhat.com>wrote:
>
>> Created PR’s for the open issues on Cordova once merged all done :)
>>
>> On 23 May,2014, at 15:18 , Daniel Passos <daniel(a)passos.me> wrote:
>>
>> All done in the android land
>>
>> -- Passos
>>
>>
>> On Thu, May 22, 2014 at 10:49 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
>>
>>> Indeed we’re all good for iOS push registration lib.
>>> ++
>>> Corinne
>>> On 20 May 2014, at 17:09, Andrea Vibelli <avibelli(a)redhat.com> wrote:
>>>
>>> > Hi,
>>> > I have reported also in https://issues.jboss.org/browse/AGCORDOVA-5an old
>>> > issue (
>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-April/007530.html)
>>> > about the google-play-services version shipped inside the cordova
>>> plugin.
>>> >
>>> > Thanks
>>> > Andrea
>>> >
>>> >
>>> > Sebastien Blanc wrote
>>> >> Hi,
>>> >> For the Cordova Push Plugin there is one (trivial) item open that
>>> should
>>> >> be
>>> >> fixed before 1.0. I created a jira to track it
>>> >> https://issues.jboss.org/browse/AGCORDOVA-4
>>> >>
>>> >>
>>> >>
>>> >> On Mon, May 19, 2014 at 2:05 PM, Matthias Wessendorf <
>>> >
>>> >> matzew@
>>> >
>>> >> >wrote:
>>> >>
>>> >>> Hi,
>>> >>>
>>> >>> as said before (see [1]), this summer we will release the AeroGear
>>> Mobile
>>> >>> Push 1.0.0 to the community.
>>> >>>
>>> >>> I took a look at the related JIRAs (see [2]) and noticed that for the
>>> >>> mobile client SDKs there are no outstanding tickets. Yay!
>>> >>>
>>> >>> The github repos are also in an OK state :-) there are no feature
>>> related
>>> >>> open PRs; Well, besides a test improvement for the Cordova push
>>> plugin -
>>> >>> but that will be addressed soon;
>>> >>>
>>> >>> My question is: Are you guys aware of any features that we need to
>>> add to
>>> >>> Android, Cordova or iOS, related for push ?
>>> >>>
>>> >>> Once the Android and iOS bits are 'done', lets make sure we use those
>>> >>> latest versions on our Cordova plugin ;-)
>>> >>>
>>> >>> Thanks!
>>> >>> Matthias
>>> >>>
>>> >>> [1]
>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-May/007675.html
>>> >>> [2]
>>> https://issues.jboss.org/issues/?jql=labels%20%3D%20MobilePush-1.0
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Matthias Wessendorf
>>> >>>
>>> >>> blog: http://matthiaswessendorf.wordpress.com/
>>> >>> sessions: http://www.slideshare.net/mwessendorf
>>> >>> twitter: http://twitter.com/mwessendorf
>>> >>>
>>> >>> _______________________________________________
>>> >>> aerogear-dev mailing list
>>> >>>
>>> >
>>> >> aerogear-dev@.jboss
>>> >
>>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >>>
>>> >>
>>> >> _______________________________________________
>>> >> aerogear-dev mailing list
>>> >
>>> >> aerogear-dev@.jboss
>>> >
>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > View this message in context:
>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Mobile-Push-1-0-0-...
>>> > Sent from the aerogear-dev mailing list archive at Nabble.com.
>>> > _______________________________________________
>>> > 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
>>>
>>
>> _______________________________________________
>> 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
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years
pipeline node.js experiment
by Lucas Holmquist
Last week i decided to start playing around with converting the AeroGear.js Pipeline library to run in node.js
I thought this would be a good place to start when thinking about how ES6 modules work, and how the code would need to be structured.
This is no doubt a WIP, but have a look see here:
https://github.com/lholmquist/aerogear-pipeline
currently it only deals in JSON
For usage checkout the tests. The Usage should be similar but since this is node.js, i’m following some of their conventions for how they do callbacks. The convention is to have a callback where the first argument is the err
an example read:
pipe.read({ id: 1 }, function(err, data, response) {
});
or to read all
pipe.read(function (err, data, response) {
});
and since this is just wrapping a http.request, it will also emit any events the http.request emits
For those wondering about my code style here, i’ve adapted the style from the yeoman project, with 1 difference, 4 spaces instead of 2
I'm not sure what part of the library could be next, datamanager might not make sense here since there is no "client side" storage per say.
I have a WIP implentation of a SimplePush client here: https://github.com/lholmquist/aerogear-simplepush-node-client
Thoughts?
10 years
Internal 'API' change for the different Senders?
by Matthias Wessendorf
Hello,
looking at the Senders, I'd like to re-introduce an interface which they
all extend:
/**
* Each implementation deals with the specific of the underlying push
network, including transforming the content of the
* {@link UnifiedPushMessage} to the proper message format of the
actual push network and maintaining the connection to it.
*/
public interface PushNotificationSender {
/**
* Sends the {@link UnifiedPushMessage} to the given clients,
identified by a collection of tokens, the underlying push network.
*
* @param variant contains details for the underlying push
network, e.g. API Keys/Ids
* @param clientIdentifiers platform specific collection of client
identifiers
* @param pushMessage payload to be send to the given clients
* @param senderCallback invoked after submitting the request to
the underlying push network to indicate the status
* of the request (<code>success</code> or
<code>error</code>
*/
void sendPushMessage(Variant variant, Collection<String>
clientIdentifiers, UnifiedPushMessage pushMessage,
NotificationSenderCallback senderCallback);
}
What's really new here is passing in a 'callback'
(NotificationSenderCallback) that gives the caller of an
PushNotificationSender implementation a hint if we could submit the
messages to the push network, or not:
/**
* A simple Callback interface used when sending {@link
org.jboss.aerogear.unifiedpush.message.UnifiedPushMessage} to
* an actual push network.
*/
public interface NotificationSenderCallback {
/**
* Simple indicator which will be called on a successful to
deliver to the push network. However, the invocation of
* this callback does <b>NOT</b> mean the messages have been sent
out to the mobile devices. The invocation simply means
* the {@link
org.jboss.aerogear.unifiedpush.message.sender.PushNotificationSender}
was able to send the messages to
* the push network for its further processing
*/
void onSuccess();
/**
* Simple indicator which will be called on any type of error that
occurred while sending the payload to the
* underlying push network.
*/
void onError();
}
The reason why I'd like to do that is this give me better access to the
state of the request (for submitting messages). That is generally a nice
thing to be aware of the request-state. For our new "push history" overview
(see related threads), this comes handy, as I have all the needed
information in a more centralized place, instead of injecting a 'Metrics'
service into all the PushNotificationSender implementations:
...
// save APNs-delivery timestamp to metrics-database
// save number of APNs tokens to metrics-database
myAPNsSender.sendPushMessage(variant, collectionOfTokensForVariant,
upsMessage, new NotificationSenderCallback() {
@Override
public void onSuccess() {
// save success status for the given variant to metrics-database
}
@Override
public void onError() {
// save failure status for the given variant to metrics-database
}
});
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years
