Right, the way I understand it is that this (task based model) is the
pervasive for Android development. I would suspect that the only
people not using this model are those that are incorrectly using "raw
threads" because they haven't picked up on the right Android
facilities.
(I'm sure there are
For me, all network activity is performed by "tasks" which are executed by
"executors" on a pool of threads.
Not Java executors, but something a bit more flexible for my needs --
priorities, cancellation, per-thread affinity based on each task's account,
etc.
The data is written to a database, se
The main hypothesis I'm wondering about is how developers pass data
from their app to the network. Since any use of the network
necessarily involves threads, there are a variety of ways this could
occur.
Most of the ways with which I'm familiar utilize methods where the
communication between the
uses-permission and permission have to be unique
On Wednesday, February 18, 2015 at 10:27:03 AM UTC-5, marten wrote:
>
> Hi all,
>
> we've some problems with Android 5. There seems to be a new policy that
> requires two apps that define the same permissions to be signed by the
> same key. Other
Sorry for the huge post, but for what it's worth, every app that I do
nowadays has the same general pattern...
I basically have a model class(es) that incorporates any logic or data that
you don't want cluttering up your views/activities/fragments and where you
would do any networking stuff. By
Agreed, thanks for the heads up!
Kris
On Fri, Feb 20, 2015 at 6:21 AM, Kostya Vasilyev wrote:
> You know, I don't. My apps aren't open source, and I came up with it myself,
> not borrowed from a library.
>
> But it's not rocket science, I'm sure you understand the pattern.
>
> -- K
>
> On Frida
Good analysis and reasoning. It leads to identifying a specific version of
the OS.
Let me add to the reasoning: If this was a bug in android-2.3.4_r1,
wouldn't many other apps that call the same function also trigger this bug?
Then the history would show a 2.3.4_r2 release with this bug fixed.
I'm seeing this with android:protectionLevel="normal" too.
Since Android doesn't grant permissions that had not been declared yet,
this forces the user to install apps declaring / using the permission in a
certain order.
This is a pain for the user, so the developer of one app that works with
You know, I don't. My apps aren't open source, and I came up with it
myself, not borrowed from a library.
But it's not rocket science, I'm sure you understand the pattern.
-- K
On Friday, February 20, 2015 at 4:39:32 AM UTC+3, Kristopher Micinski wrote:
>
> I agree, that sounds like a useful pa
Hi Marina,
we're using android:protectionLevel="dangerous" because that's what we
think is suitable for personal data like tasks. Also, it's what the
CalendarProvider uses for the permissions to read and write calendars.
At present the major issue is that some users get this error even though
10 matches
Mail list logo
