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
3 years, 8 months
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
11 years, 11 months
[UnifiedPush] Refactorings
by Matthias Wessendorf
Hi,
over the next weeks, after we get the 0.10.0 out, there will be some
refactorings on different parts of the server:
- make the 'core' the sending logic a little more isolated
- look into a better 'abstraction' for the data storage
I think this might lead to new (sub)projects and JAR files. I was
wondering, do folks like a
- pom.xml
- sender-component/
- data/
- api
- some impl projects
- pushee/ (the server as is today, but including above 'components')
- database-scripts (the CLI files for WildFly/AS)
Greetings, Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years, 11 months
Mutable vs Immutable for AGMemoryStore and AGPropertyStore
by Corinne Krych
Hello Guys,
Using AGPropertyListStorage in Xmas app [1], I run into this interesting issue:
In the app I retrieve a NSArray of NSMutableDictionary, I get a mutable copy of the NSArray and I save encrypted data in it.
I decrypt some of the data in memory BUT I actually don't want those to be saved decrypted into permanent storage.
And then let's say I add some more data with encrypted value then I save this dato to my AGProperListStorage. Just this one.
But surprise, if I look in my permenet storage, I see my newly data encrypted but the other data I ecrypted in memory were saved decrypted.
What happened?
In one word: shallow mutable copy of NSArray.
My mutable array still point to original MSMutableDictionary and when saving one data to permanent storage the all memory is dumped into plist resulting in decrypted value to be stored.
How did I fixed it?
Using deep mutable copy see in [2].
In AGMemoryStorage (and its inherited AGPropertyListStorage) we use NSMutableDictionary because you can save item (represented as Key/Value with NSMutableDictionary) without id, the store will take care of generating this id and assign it back into the item.
Even the AGMemoryStorage which returns a NSArray of NSMutableDictionary is misleading because you can actually do
NSArray myArray = [store reallAll]
and then modify the contain of the memory storage without using save.
That experience brings the topic whether it's a good pratice to use mutable object
Options
- option1: stick to immutable objects whithin the AGStore and let the save method return an immutable NSDictinary containing the item
- option2: leave it as it is, responsability of user to do deep copy
- others ?
Personal Preference go for option1 which I found less confusing.
++
Corinne
[1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
[2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
12 years
Fwd: Website restructure
by Erik Jan de Wit
Hi,
What I get from this thread is that we like the colour section idea, but we don’t want to re structure the entire site. So what we need to discuss is how are we going to use these sections if we don’t restructure. What I like about them is that it emphasises that our API’s are similar for all platforms and that we only have one document explaining for instance what pipes are. But the menu, doesn’t fit into this new colour scheme, so we need some decisions about how we are going to move forward.
Based on the work Corinne did with the introduction of sass I’ve had a go at implementing a bit what Hylke proposed, have a look at my sass branch https://github.com/edewit/aerogear.org/tree/saas and the page I’ve updated http://localhost:4000/docs/guides/aerogear-android/AerogearAndroidPipes101/ to be in section layout. Don’t look at the header and footer as I haven’t changed those.
There are a couple of things that I don’t like about the current implementation, to enable the code blocks I’ve added some html into the asciidoc and some jquery magic in the layout. Maybe we could make this better by chaining the rendering/backend or by introducing some sort of plugin into asciidoc? Other then that, I’m sure Hylke sees a lot of things that are still off, but it’s a start.
What do you think?
Cheers,
Erik Jan
p.s
example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff
12 years
Website restructure
by Corinne Krych
>
> @Hylke see my comments below
>>
>> On 24 Jan 2014, at 19:08, Hylke Bons <hbons(a)redhat.com> wrote:
>>
>>> Hey,
>>>
>>> On 24/01/2014 14:58, Corinne Krych wrote:
>>>> Hello All,
>>>>
>>>> I’ve being working on sass branch [1], the same branch Erik-Jan did its initial work.
>>>> Here is more feedback on our site redesign
>>>>
>>>> 1. Example page with each language code snippet
>>>> It’s a good idea, to show the unified aspect of our libs. Having a short snippet code is great, however it’s not possible to fit the detailed example we alreday have in our documentation. Rather than simplifying and not going into details, I think we could have a main page like [2] which give the definition + each snippet. Below the code snipet I’ve added a link:
>>>> Read more on Pipes on Android / Pipes on iOS / Paging on Web
>>>> which points to detailled page.
>>>>
>>>> I think we should keep this documetation. It goes deeper in the sample code as opposed to snippet which is not necessarly complete code. One think that we could do is use code sample extracted from our cookbook recipe. So we can point to the repository for the full app code.
>>>>
>>>> @Hylke Do you have a better idea than just a simple link? I think it’s not visual enough. And what should be the layout of the detailled example page?
>>>
>>> The [2] link is on localhost. :)
>>>
>>> How about we try it out for Pipes and see how it goes? Yes, we probably
>>> would need to move some stuff out to other sections, but that's ok.
>>> We'll have a better ideas what to do with the "excess" docs once we try
>>> any simplify the multiple documents into one.
>>>
>>> Here's the idea for the scopes I had:
>>>
>>> - Examples => High level overview of AeroGear concepts and code snippets
>>> about how they're used. Not neccesarily big programmes.
>>> - Documentation
>>> - Getting started => Download and setup
>>> - API Browser => just a link to the full API overview
>>> - Guides: We can go more all out here. Tutorials, example projects, more
>>> complex configurations, etc. Basically everything else that doesn't fall
>>> into the above categories. :)
>>>
>>> I know it's a lot of work... I do think it's the best way to go. I'd be
>>> happy to help out on this too, though I've absolutely no clue on the
>>> topic, but that may actually be a good thing for explaining stuff to
>>> people new to the concepts. :)
>>>
>>
>> Actually if you setup the sass batch link[1], you run your environment and then you go to link[2] loclhost as it’s running on our instance, you will see i’ve tried it out for Pipes. In order to do it i needed to split the documentation for iOS/Android (I haven’t done completely JS part). with this exercice what i understand is:
>> 1. the first view should contain code snippet with shows the unified aspect of client lib. those sippet are not complete code, it should be simplified.
>> 2. this simplified view is not enough for a developer. Selecting his platform tab, he will be redirected to android for ex complete description on Pipes. Ideally this description is based on a cookbook exemple.
>> 3. if the developer want to test it himself he’ll have the option to download the complete sample code (github link to cookbook repo) and just run it
>>
>> So the explantion goes through 3 layers from 1)high level description (cross platform), 2) detailled explanation linked to a platform to 3) sample code implementation (obvious linked to a platform).
>>
>> My question is How to make the transition from 1) to 2) ? See picture below
>>
https://www.dropbox.com/s/tz25vzu8doh6jkk/agorg2.png
>
>
>>
>>>
>>>>
>>>>
>>>> 5. Dracula theme vs White theme
>>>> If you uncomment [3] you can have a white theme. A shame that with Dracula theme we loose the AeroGear blue and orange logo...
>>>> @Hylke for the dracula theme we need AG logo in each of the 3 colors.
>>> Yes, I'll send you those. Don't worry about the theming too much, as we
>>> haven't really discussed that yet. The "Dracula" theme was more of an
>>> example of how we can use colours to mark different sections of the
>>> project/site. So if you'd like to see things different, let me know! :)
>>>
>>>> 5. Menu
>>>> @Hylke you said you want to remove the actual menu, but what do you propose to navigate between topic: Core/Security/Push/Sync
>>> I've actually added it back in the mockup (see the other email on the
>>> thread). It was more of a time thing that I hadn't added it yet. It's
>>> back now.
>>>
>>> Hylke
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
12 years
bower repos for custom builds
by Lucas Holmquist
so i created this JIRA https://issues.jboss.org/browse/AGJS-133
It would kind of neat if we offered some custom builds in bower,
this way it could make it super easy for someone to pull in just data manager for example
$ bower install aerogear-datamanager
each "custom" build would be in it's own repo, but they don;t have to be "aerogear" repos, similar to how the bower ember repo isn't actually an ember official repo
wdyt?
would be somewhat easier to get "new" features out without waiting on the official release
12 years
