I'm working on ftp client for android right now, In my app I wanna have 2 fragments, one for local file system and one for the remote, even though they obviosuly function differently I still want them to have the same layout, as they should look the same.
So I've been wondering, is it ok to use the same layout for different fragments or should I just copy to 2 different file?
Doesn't know if that is relevant but the fragments will definitely be active on the same time as I intend they'll both be on a pager viewer.
Also, if you could answer more generally, could two different "particles" use the same layout without problems?
Preety nooby question, but I'm new to android so...
There is no problem with this.
You can use one blue-print to build a whole bunch of houses. This is the exact same. Eventually, you might build them with separate layout files, but for now, one is fine.
Related
i developed an app that contains a lot of activities and different application within the same app and they are all interconnected by sending different intents within it to function the whole app, however they still do different things and i can elimante one without hurting the other and causing the whole app to crash. so if i want i can divide them to be stand alone apps.
My question is this:
Can i have one app that download the basic activities and if a person want a specific activity they can download it (Eg: you download a game and that game includes a different set of levels that can be downloaded by pressing a button hence downloads that particular set of levels.)?
Forgive me if I misunderstood you, but are you talking about creating one big app that consists of many smaller apps, but rather than being all bundled in the beginning, a user can download each one as a module?
If it's this, it's not impossible, but not possible in the sense that I think you're hoping for.
Your one big app will still need all the necessary code and xml files because these need to exist when compiling. But what you can do, which is similar to what games do is to offer downloadable content that isn't code. Essentially, these are resources such as media files, text, or other data of the like.
Those data can be downloaded separately without affecting your app and it helps reduce the size of your app. However, the actual functionality of each individual app will still need to be within your app, but hidden until it's downloaded.
Typically, it's more common to just bundle it all together such as a Measurements app, or to have them as individual standalone apps such as Google Docs, Sheets, and Slides.
You're basically describing how a browser/website works.
If you really wanted to wrap this up as a mobile app, you could use webviews.
I have an Activity that, with a few modifications, would work extremely well as another part of the app I'm working on. I was wondering if it's possible to easily duplicate an Activity in Android Studio without needing to manually copy all of its dependencies (activity_my.xml for example).
To get it right: You have code you want to reuse in another Activity.
Now, the way I would do this would not be to copy the reused code (because if you want to modify it, you have to modify both copies, which is tedious work).
I'd create a base-activity, that has the functionality that both of your Activities need. This functionality would have to be slightly abstracted so that both activites could use this functionality by extending this BaseActivity and use it for their individual purposes.
If you post some code (the part of code both of your activities should have), I could update my answer to show you how that would look like in your case.
I'm programming an app in Android.
My client needs a 'dummy' like application, I mean, an app with all layouts but just navigable, without the actual controllers or activities, just navigate through layouts. By clicking buttons, but just pass to the other layouts without executing java or whatever code.
My question is, is this possible in AndroidStudio?
Or should I generate another kind of graphical app in order to accomplish this?
Any ideas?
Thanks in advance!
The short answer to your question (as I understood it) is no. You have to have activities to have an android app that will function. You could create a very rudimentary set of activities to do what you want.
However, if you are simply trying to create a mockup of what the app will look like for your client, I suggest using a tool like FluidUI. This will allow you to layout the general look and feel of your app without any actual code required.
Let me know if this helps!
I have an activity with three different operations
-add
-view
-edit
I am using single activity for this and on calling i change the view by calling setContentView(xml_file_for_that_function). It works fine but as i have also just hearded about fragments and thinks it's a better approach.
I just want to ask experienced ones that IS IT VALID WHAT I AM DOING or i have to use fragments and having different xml layout for differnet functions within same activity is not a valid android approach. i.e
Though it is a valid approach to the problem, the usual way of dealing with it is in fact with fragments
If you need some help on how to use fragments here is a good tutorial from the android dev site http://developer.android.com/training/basics/fragments/index.html
I'm relatively new to Android, and I'm trying to port an app from iOS, which does something slightly unconventional.
My app has an in-house xml language for representing GUI (kind of our own nib/xib in iOS or res/layout/whatever.xml in android, believe me, we had no choice), and an inflation mechanism that inflates this xml and builds a view controller and view instances.
As a result, in iOS, my app had several live UIViewController instances of the same class (added and removed from the navigation stack as necessary) which were all inflated once (from different XMLs) and remained alive as long as the app was.
Now, I'm a bit unsure about the correct way to do this in Android. Ideally, I would like to be able to create instances of an Activity class, each with its views inflated from our xml language, and do the navigation between then. However, to my understanding this is not possible in Android (since activities are started by intents, and created by class).
Is it true that I would not be able to keep activities alive and at the same time - not on stack (i.e. "back" always kills activities)?
If so, does this mean I need to inflate the activities and all their views from xml, every time I navigate "forward" (serious performance issue), or is there an alternative?
Is it reasonable to at least save the parsed xml structure in an Application subclass, so the inflation will be faster?
Would it make sense to only send (on creation) and save (for persistency) an activity identifier to the new activity instance, and have it go to my Application subclass, and inflate itself / get its state by identifier?
In general, assuming having the GUI inflated from XML is a must, and I would like to minimize the need to re-inflate the GUI, what would you suggest as the cleanest solution?
Any other tips will be greatly appreciated… Thanks!
I am not 100% sure I understand your situation - I think what you are saying is that you've got custom XML that defines your layouts and controllers. I am going to answer based on that, correct me if I'm wrong.
First, your questions show an understanding of the problems you face if you go down your current path. I'm not going to answer them individually because I think there's a better solution - use Fragments via the compatibility package.
The way Fragments work is that you have a single Activity, then a series of Fragments inside of it that define the UI. For phones, this ends up looking the same as an Activity-based application. But in your case, it will provide a few bonuses:
Fragments can be created dynamically in code.
Fragments can be popped off the stack, but kept in memory so you can re-add them later.
You can store all of your pre-parsed XML in a retained, invisible Fragment instance (instead of the global Application subclass).
This isn't to say there are no problems with Fragments - there may be limitations there as well (I've only recently started working with them). But I would give them a look to see if they might solve your problem.
Another alternative would be to write a transformation (pre-processed) between your in-house XML and Android's XML. Android's XML View creation is pretty fast because it's optimized for it.