<div dir="ltr">Hi,<div><br></div><div>yeah - I am absolutely not against collection data :) </div><div><br></div><div>But we should be honest in our client SDK, and offer hooks to collect so data.</div><div><br></div><div>
I was saying the Orbiter SDK says "registerToken" - however it sends more data... we should make that API more fluent and indicate _WHAT_ the lib is submitting to the server. (instead of doing that silently :)) (Sure.... the end-user (user of the phone/app) will never really notice what get's collected, but that's a different story)</div>
<div><br></div><div>As you said, there are some things that are really required:</div><div>- token</div><div>- os (+version)</div><div>- device type<br><div class="gmail_extra"><br></div><div class="gmail_extra" style>Also.... there maybe data that we can't think of... so the API needs to be flexible: I should be able to accept a NSDictionary, where users can store what every they want/need</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 12, 2013 at 11:11 AM, Apostolos Emmanouilidis <span dir="ltr"><<a href="mailto:aemmanou@redhat.com" target="_blank">aemmanou@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div><br>
I'm aware that telecommunication organizations are collecting the below<br>
information through their mobile apps.<br>
OS version<br>
OS platform<br>
First date opened the app<br>
Last date opened the app<br>
Device model<br>
2G/3G/4G enabled or WI-Fi flag<br>
Location<br>
Obviously the Apple token id for APN<br>
<br>
This information is transferred from the IT department to the<br>
CRM department. Marketing specialists are analyzing the collected<br>
information and creating business rules which break the whole set of<br>
information to smaller subsets. Then these rules are returned back to<br>
the CRM department and personalized push notification campaigns are<br>
created. For example if you have an iPhone 4 and you're mostly<br>
connected to the network through 3G then maybe you're a possible<br>
customer for iPhone 5 + 4G.<br>
<br>
In conclusion I believe that an optional API which is able to collect<br>
some information about the user/usage of a mobile app would give some<br>
value.<br>
<br>
</div>Thnx,<br>
Tolis Emmanouilidis<br>
<div><br>
On Mon, 2013-04-08 at 18:27 +0200, Matthias Wessendorf wrote:<br>
</div><div><div>> Hello,<br>
><br>
><br>
> I took a look at the Helios server<br>
> (<a href="https://github.com/helios-framework/helios" target="_blank">https://github.com/helios-framework/helios</a>).<br>
><br>
><br>
> It is a Sinatra based "Web UI", on-top of a PostgreSQL Database, which<br>
> has a RESTful endpoint to accept device registration information/data;<br>
><br>
><br>
> On the (iOS) client, they recommend the usage of the Orbiter client<br>
> framework (a simple wrapper around AFNetworking);<br>
><br>
><br>
> I am not planing to use the Orbiter client framework, but just to<br>
> layout the level of data which, MAY be stored for a registered<br>
> "application installation" on a device<br>
><br>
><br>
> It has nice hooks to provide a "quite time", for disabling message<br>
> delivery in a certain time interval:<br>
><br>
> <a href="https://github.com/mattt/Orbiter/blob/master/Orbiter/Orbiter.h#L86-87" target="_blank">https://github.com/mattt/Orbiter/blob/master/Orbiter/Orbiter.h#L86-87</a><br>
><br>
><br>
> However, the framework collects a lot of other data as well :)<br>
><br>
><br>
> For instance... it collects location data (if enabled, on the device),<br>
> but the API doesn't really tell you that - it's collected by the<br>
> implementation:<br>
> <a href="https://github.com/mattt/Orbiter/blob/master/Orbiter/Orbiter.m#L100-101" target="_blank">https://github.com/mattt/Orbiter/blob/master/Orbiter/Orbiter.m#L100-101</a><br>
><br>
><br>
> So I was surprised to see that in the JSON response :-)<br>
><br>
><br>
><br>
><br>
> Sure... it's useful - for some apps - but I think... If we want to<br>
> allow our uses to store that kind of data, we should:<br>
> - add API hooks (into the client SDK) - may become 'verbose'... after<br>
> a while<br>
> - show how to do that and use a generic API (e.g. NSDictionary)<br>
><br>
><br>
> At a low-level, we really "just" require the device token and the<br>
> version/variant of the os (e.g. iOS 6.1.3). Any other data is APP<br>
> specific and really needs to be defined by the application developer<br>
> that is using our bits.<br>
><br>
><br>
><br>
><br>
> Any thoughts ?<br>
><br>
><br>
> --<br>
> Matthias Wessendorf<br>
><br>
> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
</div></div><div><div>> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div></div>