Database Users

Linked List passing

I load a linked list of objects (i.e. a struct) at start of app. I want to pass the whole linked list to other Activity(s).
I can do linkListName.toArray() and pass via put.extra and re-create linked list in next Activity, but it just doesn't "feel" clean! ROFL
And most likely it's pass by value, not by reference (not sure if that makes a difference in my app yet, but I bet I'll need a pass by reference call). I've also read about Serialization and Parcels, but I think those are pass by value implementations too.
What I want to avoid is passing a linked list around my app; I would like to load it once, be able to have my custom class do whatever I need (adds, edits, deletes, moves etc.) on it.
Any ideas? I know I could probably just do everything in ONE Activity and just change my ContentViews as required, but I've read that can be troublesome. And note that I"m trying very hard to stay away from any database implementation just because I've done the database thing too many times.
TIA,
Roots

You could make the linked list protected instead of private and just pass a flag that tells your other activity to just access it via SomeActivity.myLinkedList
Protected makes the variable accessible by other classes in your package but not outside
From something awesome

And static...
From something awesome

Well ****, should have known that....THANKS! Guess my OOP is a bit rusty :-( ugh, I got it....seems to be ok...that is, I can see my methods when I do "ClassName.LinkedListName. "
Thank you so very much!!!!

Its happened to me before. Ive gotten caught up in Android Intents, Bundles, Extras, etc and was struggling to pass something till i stepped back and realized im still in Java... Its more of a mindset thing than anything else
From something awesome

08-06 15:46:27.354: INFO/System.out(408): This default is true
08-06 15:46:27.354: INFO/System.out(408): This default is false
Ha! My setter and getter methods are working across Activities! Woo Frikkn' Woo...I could send you $100 for that reply I'm so happy! Note to self: Must remember to write changes to file.
Just a note to ALL programmers, new and old: If you're trying to do something and it seems extremely difficult, you're probably doing it wrong. Go back to the basics and keep it simple stupid!

[GUIDE] Using the Share Intent

Hello everyone,
While making an app, I wanted to let the user be able to share some content (shameless plug: from a clearable EditText). So, I looked up how to do this.
In this thread, I will share (pun not even intended) with you how to use the Share Intent yourself, so that your users can also quickly involve anyone they know in what they're doing.
There are some things that I am going to assume you've done:
- You have made your base app
- You have a Button done and set up, only needing a method to execute the Share Intent.
Now, let's get to it!
Step 1 - The method:
First, you have to set up the method. As always, give it a nice and descriptive name, so everyone (including you later, believe me that you'll need it) knows what it does.
Of course, this just follows standard syntax. I'm going to name it share, because simple!
So, you'll get this:
Code:
private void share() {
// This is the method where we share some content
}
Step 2 - The Intent:
You want to make sure that Android recognises your Intent as being a Share Intent. Of course, because of the flexibility of Intents, this is also easily done. Just declare another parameter, which isn't the usual set of Classes.
My Intent will be called shareIntent.
Like so:
Code:
Intent shareIntent = new Intent(android.content.intent.ACTION_SEND);
Step 3 - The type:
When sharing content in Android, you have to let the system know what you're sharing. Naturally, it has to react differently to different types of content. An image can be handled by certain apps, while others can only handle text. Apart from that, the apps have to process the items differently.
This is done by declaring the MIME type, which are unique identifiers for different data types.
Some possible types are text/plain, image/gif and video/mp4.
In this case, we are going to share some text. This is done by adding the following line under the Intent declaration:
Code:
shareIntent.setType("text/plain");
With the setType method, you could target specific apps. However, this is obviously not a good idea. If a user doesn't have that app on their phone, it'll cause trouble. Therefore, just use the right type and let the user select the relevant application.
Step 4 - The Content:
Now for the real work. What are you sharing? Of course, text! But you have to give the Intent that text, because it won't just snuff it out by itself.
How do we do this? Simple, again.
Just create a String and use that. Of course, you can hard code a String in the Intent, but it's best to use a variable. After all, you're probably going to be sharing dynamic content.
This is done as follows, though you should really know this by now:
Code:
String sharedString = "Hey, we are sharing!";
Step 5 - The extras:
You have to also give the Intent its extra information. For this example, we'll be setting two types of extras: a subject and the body.
This way, there is flexibility. If the user chooses to share the text using an email application, the subject will also be used. If they don't, it won't be used.
This is done by adding the following lines to your sharing method:
Code:
shareIntent.putExtra(android.content.Intent.EXTRA_SUBJECT, "This is the subject");
shareIntent.putExtra(android.content.Intent.EXTRA_TEXT, sharedString);
Step 5 - The Chooser:
Whenever you share something, you see the Dialog pop up for you to select the app you want to use in your sharing the content. This is the next and last step in this guide, and is basically just starting the Intent with a special parameter.
Not every type of media can be shared to every app. When you share certain content, Android looks at what apps have declared themselves candidates for that MIME type.
So, if you are not seeing certain apps appear, check whether the app can work with that MIME type!
Start the Intent like this:
Code:
startActivity(Intent.createChooser(shareIntent, "Share via"));
Of course, the title to the chooser doesn't have to be "Share via". It can be any other text or variable (keep this in mind for apps that have translations!).
Facebook doesn't do this right! The facebook app doesn't do sharing right, so it will probably not show up in the list of apps that you might see when following the tutorial. To counteract this, target the app using the specific API.
Have fun sharing, and thanks for reading!
P.S.: Images can be added, should anyone want me to do so.

I also found this for the ActionBar very interesting: http://developer.android.com/reference/android/support/v7/widget/ShareActionProvider.html

nikwen said:
I also found this for the ActionBar very interesting: http://developer.android.com/reference/android/support/v7/widget/ShareActionProvider.html
Click to expand...
Click to collapse
True, the ShareActionProvider is quite nice but has one really big downside: You have to update it with the Intent BEFORE the user clicks the item, and there is no workaround. So if you want to generate an image when the user clicks share, you cannot use the ShareActionProvider.
And thanks for the guide OP!

SimplicityApks said:
True, the ShareActionProvider is quite nice but has one really big downside: You have to update it with the Intent BEFORE the user clicks the item, and there is no workaround. So if you want to generate an image when the user clicks share, you cannot use the ShareActionProvider.
And thanks for the guide OP!
Click to expand...
Click to collapse
Wouldn't it be possible to extend the class? Maybe it could be achieved that way.

nikwen said:
Wouldn't it be possible to extend the class? Maybe it could be achieved that way.
Click to expand...
Click to collapse
Could work, but I have no idea what methods to override... I need to have a closer look at this.

[Q] How do i get the Time an App is currently Running?

Hallo everbody,
im writing a background service to get informations like the time an active app (not my app) is running.
With this information i can show the user a list of the most used apps depending on the time.
The methods of the ActivityManager-class are useless, because the received informations aren't reliable.
So i thought, because the Android-System is based on a Linux-Kernel, i can use the internal structure to get these informations.
So i read out the pseudo proc-filesystem to get the process informations and for the 2nd time i thought
thats the right place for me to get what i want.
I read out the stat-file in every single process-directory to get the starttime(in clock_ticks) of the process.
I dynamic calculate the HZ USER_HZ value and use it to get the real starttime but this time never changes.
It's more like a timestamp of the first start on the system after boot.
The user-code-time and kernel-code-time seems to be too short and the values are updated too irregular.
So i just got a time value, that tells me the time when the app was first started after system boot
but i want a timestamp or anything else i can get from a currently running app to calculate the time this app is active.
Long life services and background services are not my goal.
Now i'm here because i don't know if i just miscalculate the values from this pseudo filesystem or
if i'm absolutely wrong where i get my informations from.
My Questions:
1. Do i read the wrong values files filesystem (if yes, where can i find these informations in the system structures)
2. Do i misunderstand some of the values i read out
3. Why do the files in the process directories become updated so irregular or once in a lifetime (just if im in the right filesystemfile)
I hope u can help me. *-*

Well, interesting approaches. :good:
The only way I see is running a background service and storing the launch time yourself.
I'm sorry but I don't know the answers to your questions.

You could
a) use su to get the active process list
b) get to /proc/??? folder (where ??? is the apppropriate process you enquire, for example /proc/80/)
c) get the /proc/80/sched text file and look for exec_runtime or vruntime or what ever works for you

carbonpeople said:
You could
a) use su to get the active process list
b) get to /proc/??? folder (where ??? is the apppropriate process you enquire, for example /proc/80/)
c) get the /proc/80/sched text file and look for exec_runtime or vruntime or what ever works for you
Click to expand...
Click to collapse
Oh, getting the currently running tasks can even be done much easier and doesn't require root. This is what I use:
Code:
ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
List<ActivityManager.RunningAppProcessInfo> processInfoList = am.getRunningAppProcesses();

carbonpeople said:
You could
a) use su to get the active process list
b) get to /proc/??? folder (where ??? is the apppropriate process you enquire, for example /proc/80/)
c) get the /proc/80/sched text file and look for exec_runtime or vruntime or what ever works for you
Click to expand...
Click to collapse
that seems to be exactly what i need!
but there are the next questions:
what is the unit of the "se.sum_exec_runtime"-field? is it in nano-secs?
what does the point do in the value? does it indicates a floating-point value?
im kinda confused and didnt really find something meaningful about the unit (*-*)
and im not very handy with the kernel code from "lxr.linux.no"

nikwen said:
Oh, getting the currently running tasks can even be done much easier and doesn't require root. This is what I use:
Code:
ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
List<ActivityManager.RunningAppProcessInfo> processInfoList = am.getRunningAppProcesses();
Click to expand...
Click to collapse
Following Note can be found in the android-doc:
"this method is only intended for debugging or building a user-facing process management UI."
And the "RunningAppProcessInfo"-class (given by the Method) doesnt provide any infos about the running time of a process.
So i think it's more reliable for me to read out the process-infos directly in the proc-filesystem.

Dalorikai said:
Following Note can be found in the android-doc:
"this method is only intended for debugging or building a user-facing process management UI."
And the "RunningAppProcessInfo"-class (given by the Method) doesnt provide any infos about the running time of a process.
So i think it's more reliable for me to read out the process-infos directly in the proc-filesystem.
Click to expand...
Click to collapse
1) True.
2) That's why I wrote this:
nikwen said:
The only way I see is running a background service and storing the launch time yourself.
Click to expand...
Click to collapse
3) But if the other method works and if you don't care about root rights as a requirement, it might be better. :good:

Dalorikai said:
what is the unit of the "se.sum_exec_runtime"-field? is it in nano-secs?
what does the point do in the value? does it indicates a floating-point value?
im kinda confused and didnt really find something meaningful about the unit (*-*)
and im not very handy with the kernel code from "lxr.linux.no"
Click to expand...
Click to collapse
replying to my own post i think the point in the value of the field indicates the milli-secs.
just an idea - im not sure but would be plausible if the unit is nano-secs.
what do u think or possibly know? ^^

Way to store Preferences

Hey Guys,
I am creating a app to rename other apps via xposed and the main code is written. Now I simply want to make a interface where you can define a app to rename and then enter a new name. For the beginning I thought about a Activity where you enter the Package Name and the desired name. Later on I want to use a list view to show all apps, from where you can choose one to rename(Like App Settings etc.). To show the renamed apps I want to use a ListView. Now I am stuck with a problem: My xposed code works with an array to check and rename. The list view can be used with an array or an arraylist, but I need a way to store the preferences(which are stored in a array).
Do you have a good idea or a sample how to realise this? And does somebody know a nice App List type of thing(I googled, but the project there aren't usable with my kind of approach.)

GalaxyInABox said:
Hey Guys,
I am creating a app to rename other apps via xposed and the main code is written. Now I simply want to make a interface where you can define a app to rename and then enter a new name. For the beginning I thought about a Activity where you enter the Package Name and the desired name. Later on I want to use a list view to show all apps, from where you can choose one to rename(Like App Settings etc.). To show the renamed apps I want to use a ListView. Now I am stuck with a problem: My xposed code works with an array to check and rename. The list view can be used with an array or an arraylist, but I need a way to store the preferences(which are stored in a array).
Do you have a good idea or a sample how to realise this? And does somebody know a nice App List type of thing(I googled, but the project there aren't usable with my kind of approach.)
Click to expand...
Click to collapse
Ah the data storage problem... I think we all came across this at least once . I suppose you read this guide on the different options available? Well there are actually three options: SharedPreferences, text or csv file and SQL.
The first one would need some work around and is probably the slowest. You would save a separate string directly into the SharedPreferences (maybe in a new file to avoid collisions?) with the array name and its index somehow in the key. That's just two methods of coding but not the nicest way to do it.
The text or csv file however is the more common way, here you'd save your array in one line of the file, each item separated with a ; or some other char. Needs a bit more coding and also the WRITE_EXTERNAL_STORAGE permission on preKitKat if I remember correctly.
The third one is the nicest and most modular one. Because it makes use of SQL it needs quite a bit of knowledge and some coding (but less than the text file).
I guess for simple things that you want to do it is better to stay away from SQL for now unless you know how to use it and use the SharedPreferences.
Edit: take a look at the answers to this question, they give you the code as well... And you can use StringSets in ICS and above if the order of your list doesn't matter !

I'd say go down the SQLite DB way, chances are that if you plan on expanding your coding knowledge and want to keep creating apps you'll be needing to learn this in the future anyway so why delay?
Google AndroidHive and look at their SQL tutorial - I used it when learning and found it very informative
Sent from my HTCSensation using Tapatalk

Thank you very much! As coming from windows, first of all I thought about SQL as well, but it seems oversized for the set of data i want to store. I also took a look at the stackoverflow thread you linked. It looks easy to implement, but the need to use an external class file made me look for another way. I found this one, which works pretty well for me, as I look forward to interchange the method of saving the data with a better one using the SharedPreferences(which actually should be really easy with my code).
Maybe you can tell me yet another thing: Is there a way of declaring an object(like the ArrayList) to make it accessible from every class except from giving every class(activity) it's own "load the preferences" and "save the preferences" code block or sending intents all over the place? This would make saving much easier and allow me to update the preferences during runtime and without a reboot
Edit: This was my answer to.SimplicityApks ^^ I'll take a closer look at SQL now, since you, Jonny, told me that it' nevertheless necessary.

GalaxyInABox said:
Thank you very much! As coming from windows, first of all I thought about SQL as well, but it seems oversized for the set of data i want to store. I also took a look at the stackoverflow thread you linked. It looks easy to implement, but the need to use an external class file made me look for another way. I found this one, which works pretty well for me, as I look forward to interchange the method of saving the data with a better one using the SharedPreferences(which actually should be really easy with my code).
Maybe you can tell me yet another thing: Is there a way of declaring an object(like the ArrayList) to make it accessible from every class except from giving every class(activity) it's own "load the preferences" and "save the preferences" code block or sending intents all over the place? This would make saving much easier and allow me to update the preferences during runtime and without a reboot
Edit: This was my answer to.SimplicityApks ^^ I'll take a closer look at SQL now, since you, Jonny, told me that it' nevertheless necessary.
Click to expand...
Click to collapse
Welcome
You mean you want to make your ArrayList, which is an instance variable in the activity, accessible to every other class within your package without having an instance of your activity at hands? Well the basic solution would be to make the ArrayList static. But that is not recommended because it won't be created and garbage collected at the same time as your activity and also it's not a nice way .
If you had an instance of the activity it would be just using a public getter for it, but without I'd put your ArrayList into a separate class following the Singleton pattern. That way you have only one global instance which contains the ArrayList.

Thanks again for your reply! I changed my mind about the ArrayList and created a method, where everything is stored in the SharedPreferences and the ArrayList's only purpose is the use with the ListView and Adapter. This way I don't have to write the ArrayList to the SharedPreferences and changes will be much easier to control. Although I had to implement another type of save/load method to interact with the class thats being loaded by xposed. That was needed because of the restriction that you can only load SharedPreferences with a context, which my class doesn't have. It's an inconvenient way, but it works

Intent filters

Ok so i used to be a very experienced actionscript user. But i recently wanted to get back into programming so im learning java now or rather trying to.
So im trying to understand the xml side of this so far and have some questions im hoping u guys can answer.
activities
So as i understand it an activity is a screen in an app. So for example the standard launcher on my phone has pages of apps on my main screens. Each one of those would be an activity? And then another activity for when i press the button to display all installed apps?
Have i understood that properly?
intent filters
This is where im getting confused. Ive googled it and read as much as i can find. As i read it, feel like someones explaining rocket science to a 5 year old.
The words component and instances is being thrown around enough that i got no clue whats even being said. What i have understood is it gives data to the activity.
So a best guess from my partwould be its telling it how the screens going to work or maybe like if theres going to be a button on it maybe. Or perhaps it means something different like just the properties sort of stuff like screen size or stuff of that nature.
As u guys can probably tell im confused beyond comprehension. I got no idea how good my grasp is of any of this. But if theres someone out there kind enough to dumb it down a bit so normal people can understand it. Id be very gratefull.

Bump

Bump

Hey,
unfortunately i cant answer your question. This is a part of android I don't understand too.
I think you should post your question again in the Question and Answer forum of XDA. http://forum.xda-developers.com/android/help maybe there is an developer who can help you.
Greetings

Thanks ill post there and see if it makes any difference

Android apps run in sandboxes. Consider a huge box partitioned into 'n' number of sections. Each partitions represent a place in android environment where app can reside. By sandboxing, app are given unique ID(UID) when they start a process. Only apps having same (UID) can access the app's resources so no malicious app can peek into the resources of other app.
If apps cannot see other resources, how could they communicate within apps? Thats where intent comes in. Intents are like post letters and android is the postman. You can either give:
1. Recipient address, here, the package name of the app for which the intent is to be sent and may include your data in the intent if there is any and the postman (android) delivers it to the right person (target app). This is also known as explicit intent because you know the target class to call
2. Intent filter - This is not as specific as the first one. Here, your app has to perform something using an external app but your app doesnt know of the other apps which could perform the action. So, this time it will go for a broadcast and say "Hey! I need to take a picture! All camera apps please come in" and the broadcast is sent by android which displays list of apps which respond to this broadcast. When the user chooses the app to perform the action, the app fires, performs the task for your app, return the data to your app in form of intent result.
To register an app to respond to this type of intent, the app specifies something called intent-filter in their manifest which says the android, in our example context "I can perform camera action". So next time intent for camera action is sent, the app is in the list of apps to perform action with. This type of intent in implicit intent as you let the android and user decide the app. You can also specify your own custom intent-filters apart from standard android ones.

vijai2011 said:
Android apps run in sandboxes. Consider a huge box partitioned into 'n' number of sections. Each partitions represent a place in android environment where app can reside. By sandboxing, app are given unique ID(UID) when they start a process. Only apps having same (UID) can access the app's resources so no malicious app can peek into the resources of other app.
If apps cannot see other resources, how could they communicate within apps? Thats where intent comes in. Intents are like post letters and android is the postman. You can either give:
1. Recipient address, here, the package name of the app for which the intent is to be sent and may include your data in the intent if there is any and the postman (android) delivers it to the right person (target app). This is also known as explicit intent because you know the target class to call
2. Intent filter - This is not as specific as the first one. Here, your app has to perform something using an external app but your app doesnt know of the other apps which could perform the action. So, this time it will go for a broadcast and say "Hey! I need to take a picture! All camera apps please come in" and the broadcast is sent by android which displays list of apps which respond to this broadcast. When the user chooses the app to perform the action, the app fires, performs the task for your app, return the data to your app in form of intent result.
To register an app to respond to this type of intent, the app specifies something called intent-filter in their manifest which says the android, in our example context "I can perform camera action". So next time intent for camera action is sent, the app is in the list of apps to perform action with. This type of intent in implicit intent as you let the android and user decide the app. You can also specify your own custom intent-filters apart from standard android ones.
Click to expand...
Click to collapse
Gave u a thanks fkr that very useful responce. Thank you. So if ive understood this right. If i want to take a picture for example the intent filter part basically calls out for an external app to perform the action. With intent filter so basically when an app asks u with that menu what app youd like to choose thats an intent filter? And implicent thats the same menu or android just chooses it for you? Im trying to picture it from the user-side
Recipient address seems straight forward. You know u need an app and what its called. So u dont even need the user to select anything.

scorpafied said:
Gave u a thanks fkr that very useful responce. Thank you. So if ive understood this right. If i want to take a picture for example the intent filter part basically calls out for an external app to perform the action. With intent filter so basically when an app asks u with that menu what app youd like to choose thats an intent filter? And implicent thats the same menu or android just chooses it for you? Im trying to picture it from the user-side
Recipient address seems straight forward. You know u need an app and what its called. So u dont even need the user to select anything.
Click to expand...
Click to collapse
Your understanding on implicit intent is correct. To make it even more short an precise,
An intent is an abstract definition of the operation to be performed by the app
Click to expand...
Click to collapse
When the target action is known, say you invoke a second activity of you app. You know the target action (the class name), that is your implicit intent. You decide what action to perform without user intervention here. Explicit usually needs user input for inter-app communication to take place.
Examples of few implicit intents:
Starting an activity
Starting a service

vijai2011 said:
Your understanding on implicit intent is correct. To make it even more short an precise,
When the target action is known, say you invoke a second activity of you app. You know the target action (the class name), that is your implicit intent. You decide what action to perform without user intervention here. Explicit usually needs user input for inter-app communication to take place.
Examples of few implicit intents:
Starting an activity
Starting a service
Click to expand...
Click to collapse
Ok cool. So recipient is when we choose the app. Intent is whwn they get a menu to choose it. And implicent is is when android chooses it for them.
Sounds simple enough. Thanks for all the help buddy
And would i be right in assuming that the actions we put in intent filters and the others in form it of stuff like when its triggered, how often and so forth?