I'm using this library project in my Android application. But I need to make some customization for it.
For example, if I need a EditText instead of the provided TextView, what is the best practice to customize the library for my needs without writing code in the Project Library?
I made this customization by defining in the library's actionbar.xml layout a EditText instead of TextView, but I don't like this approach.
Do you have any guidelines, tutorials that could help me out?
In your special case I would suggest to use original compatibility's-package actionBar.
But to answer your question: you could always extend classes from the Library, which I think is the best practice if the library should kept untouched. Overriding Methods which you want to change their behavior keeps anything clean. You do the exact same every time you extend android-sdk classes, which you cannot change like you want.
In the case of changing layouts I'm not quite shure. I think I can remember that if the lib has an actionbar.xml and you have an actionbar.xml inside your project, too, yours will win. just like an "overriding layouts" feature
Related
I have to make a new design for an Android App, but I only have to create the visual part (native Android). The app logic would be created by another guy based on what I present to him.
My question is? How would this be managed correctly? Do I have to make the XML's of each layout? How could I show the other person my progress?
What things should I consider when doing this?
Thanks
You need to mock the app first (create a prototype) as suggested by NoChinDeluxe. Then if you guys go ahead and decide to code it, the answer to your problem is separation of responsibilities. As Jeffrey said UI work is not only about layouts, but code as well. What I would suggest is that you and the other guy get together first and define some contracts (interfaces) that will allow you guys to split the work and work in parallel. Therefore, he can create the business logic of the app without worrying about the UI implementation. You, on the other hand, will have to mock that business logic he's implementing at the beginning so it doesn't block your UI work.
you could create layout XML files for all the Activities/screens, using resources (icons, etc as suggested by #NoChinDeluxe). However since you'd want to run the mock app, you might want to also create a "throw-away" Activity that allows you navigate to different screens of the app. Here you can add a number of buttons and when you click on each button, your app shows a specific activity. This way, you will be able to show your colleague all the screens you have created. I hope this helps.
This may not be what you want to hear, but creating Android layouts isn't a design task. They are closely tied to the code, and the design of them is going to depend on how the engineer chooses to implement the app.
Here's an example. You might have a grid with 4 cells. You could use a RelativeLayout, a LinearLayout, or GridLayout, or a GridViewLayout. Which will use choose?
I'd suggest providing your engineer with mockups and graphical assets where required. Let him / her take those and create the layouts. If you want to create layouts as a (visual-only) reference for engineering, great, but it's certainly a non-optimal tool for that task.
Things You will consider when doing visual part:-
You have to work on the resource folder of your application
Layout : All Layout you have to prepare.
Drawable : Images and drawable .xml.
Inside Values folder you will find
dimen.xml : For different devices dimen you can set.
string.xml : You can store string for hint or other purpose.
style.xml : For designing or theme or custom design.
color.xml : Color which are going to used in the application.
I was trying to implement preferences for an AppCompat app, using support.v7.preference. It took me a couple of days to fiddle through it, since support.v7.preference has some significant differences to the native preferences... which isn't too bad once you know, but unfortunately there's little documentation out there. I thought I'd share my findings so others don't have to go through the same pain.
So... question:
How do you best implement Preferences for AppCompat apps (with PreferenceFragment and AppCompatAcitivity being incompatible)?
Here are a couple of related questions:
Preference sub-screen not opening when using support.v7.preference
How to move back from Preferences subscreen to main screen in PreferenceFragmentCompat?
PreferenceFragmentCompat requires preferenceTheme to be set
How do I create custom preferences using android.support.v7.preference library?
Official docs here:
http://developer.android.com/guide/topics/ui/settings.html
http://developer.android.com/reference/android/support/v7/preference/Preference.html
Solution 1: Native PreferenceFragment with AppCompatActivity
In AndroidStudio, choose File > New Project >...> SettingsActivity. This template uses a workaround that retrofits the native PreferenceFragment to work with AppCompatActivity, similar to the support.v4.Fragment or the support.v7.PreferenceFragmentCompat.
Pro: you can now use the native Preference functionality within an
AppCompat app. It's a quick approach when using the AS template, and you can stick to the existing Preference docs and workflows.
Con: the retrofitting isn't very intuitive or clean. Also since it's usually advisable to use support libs where available, I'm not sure how future-proof this approach is.
Solution 2: support.v7.preference.PreferenceFragmentCompat with AppCompatActivity
Pro: maximizes compatibility
Con: a lot of gaps to bridge. Also this might not work with any of the existing preference-extensions-libs out there (eg. ColorPicker or FontPreferences).
Should you choose not to use Solution 1 (I'm still not sure which of the two is more future proof), there are a couple of drawbacks when using support.v7.preference.
Important drawbacks of using Solution 2 are mentioned below.
Dependencies:
dependencies {
...
compile 'com.android.support:appcompat-v7:23.1.1'
compile 'com.android.support:preference-v7:23.1.1'
compile 'com.android.support:support-v4:23.1.1'
}
Theme:
You'll need to define a preferenceTheme in your styles.xml, otherwise running your app will raise an exception.
<!-- Base application theme. -->
<style name="AppTheme" parent="Theme.AppCompat.Light">
<!-- Customize your theme here. -->
<item name="preferenceTheme">#style/PreferenceThemeOverlay</item>
</style>
You might wanna split this into different styles for 7+/14+/21+. A lot of people complain about this being buggy at the time of this writing. There is a very comprehensive answer available here.
Behavior changes: using the native preferences is extremely straight forward: all you need to do is define/maintain your preferences.xml and use addPreferencesFromResource(R.xml.preferences) within your PreferenceFragment. Custom preferences are easily done by sub-classing DialogPreference, and then just referenced to within the preferences.xml... bam, works.
Unfortunately, support.v7.preference has had everything related to dealing with Fragment stripped out, making it loose a lot of it's built-in functionality. Instead of just maintaining an XML, you now have to sub-class and override a lot of stuff, all of which is unfortunately undocumented.
PreferenceScreens: PreferenceScreens are no longer managed by the framework. Defining a PreferenceScreen in your preference.xml (as described in the docs) will display the entry, but clicking on it does nothing. It's now up to you to deal with displaying and navigating sub-screens. Boring.
There is one approach (described here), adding a PreferenceFragmentCompat.OnPreferenceStartScreenCallback to your PreferenceFragmentCompat. While this approach is quickly implemented, it simply swaps the content of the existing preference fragment. Downside is: there is no back navigation, you're always 'at the top', which isn't very intuitive for the user.
In another approach (described here), you'll also have to manage the back stack in order to achieve back navigation as expected. This uses preferenceScreen.getKey() as a root for each newly created/displayed fragment.
When doing so, you might also stumble over the PreferenceFragments being transparent by default and adding up oddly on top of each other. People tend to override PreferenceFragmentCompat.onViewCreated() to add something like
// Set the default white background in the view so as to avoid transparency
view.setBackgroundColor(ContextCompat.getColor(getContext(), R.color.background_material_light));
Custom DialogPreference: Making your own preferences has also gone from trivial to boring. DialogPreference now has anything that deals with the actual dialog, removed. That bit now lives in PreferenceDialogFragmentCompat. So you'll have to sub-class both, then deal with creating the dialog and displaying it yourself (explained here).
Looking at the source of PreferenceFragmentCompat.onDisplayPreferenceDialog() shows that it knows how to deal with exactly 2 dialog preferences (EditTextPreference, ListPreference), everything else you'll have to implement yourself using OnPreferenceDisplayDialogCallbacks... one wonders, why there is no functionality to handle sub-class of DialogPreference!
Here is some code that implements most of these workarounds and boxes them in a lib module:
https://github.com/mstummer/extended-preferences-compat.git
Main intentions were:
Remove the need to extend and fiddle with Activity and PreferenceFragment in each app/projects. preference.xml is now again the only per-project file to change/maintain.
Handle and display PreferenceScreens (sub-screens) as expected.
Un-split DialogPreference to restore the native behavior.
Handle and display any sub-class of DialogPreference.
Don't think it's clean enough to be just used out of the box, but it might give you some hints when dealing with similar issues. Give it a spin and let me know if you've got any suggestions.
I have an alternative solution to this, that i'd love feedback on.
I made a custom layout for my preferencefragment, with a "Back" button in the upper left corner.
First, in the "onCreatePreference" i store away the root PreferenceScreen:
root = this.getPreferenceScreen();
Then, I add the OnPreferenceStartScreenCallback as described above and in other threads to make the fragment go to subscreen, but in my "onPreferenceStartScreen" i also set the back button to visible like this:
public boolean onPreferenceStartScreen(PreferenceFragmentCompat preferenceFragmentCompat, PreferenceScreen preferenceScreen) {
preferenceFragmentCompat.setPreferenceScreen(preferenceScreen);
backButton.setVisibility(View.VISIBLE);
return true;
}
Finally, the backButton clickhandler:
setPreferenceScreen(root);
back.setVisibility(View.GONE);
This seem to work fine for me. Obviously the back stack won't work, but i can live with that since there is a Back button.
Not perfect, but given the abysmal API i think i'm happy.
I would love to hear if someone thinks there are any problems with this approach.
I am in a situation like i have to generate UI Controls like Button,Switcher,Progress Bar, Label text etc based on my list Items .
I am looking for a way to generate the controls in a View and add Views with generated controls in a Layout .
Can anyone give me a proper way to do that?
Why not to use Fragments?
Google docs about this here
and little tutorial here
You may want to take a look at the Metawidget source code. The Android version of Metawidget makes extensive use of generating Views and Layouts at runtime (e.g. see org.metawidget.android.widget.widgetbuilder.AndroidWidgetBuilder). You may even find Metawidget itself will suit your needs (it's designed to be embedded into projects for use-cases such as this).
I am working on an application that involves me having to place a toolbar at the bottom of each activity. The toolbar will have 4 buttons on it, each starting new activities.
I am just wondering, and I apologize for how general the question, is there a proper way to go about implementing this? my plan was to but a linear layout element in each xml layout file with horizontal orientation. Then four button elements inside of that...
It seems like a huge amount of work considering I will have a lot of activities..
What you want sounds a lot like Android's ActionBar. Check this link for a guide to its usage. If you use this, your app will look and feel more consistent with the operating system, as so many apps now use the ActionBar (which is a lot of them), and you gain a lot of power for what you want to show there, and how you want to do it.
ActionBar was only introduced in Android version 3 (Honeycomb), but there's a compatibility library, ActionBarSherlock which allows you to use it in older versions of Android as well.
Hope it works for you!
You can use a same xml for various views. So I suggest creating a generic xml, then using Inflaters and other resources as strings, xmls etc. to prepare the generic xml whenever any Activity is loaded. So you can reuse it the xml.
I have know core java, I want to develop android apps, in few sites I saw apps in XML in few Java.Which is best and easy to use Java or XML?
I'm assuming you are talking about the UI, not the complete app:
For everything statically I use XML, because it is easy to find in the structure of your project.
Some parts you want to create dynamically and you have no other choice then to use Code. Be smart, in this, so if you have to add several Views that look the same do this
Make an XML with your views
In the loop where you are adding the several Views, inflate this xml, set your id's etc, and add them
You can have all the basics, styles etc in your XML, and still add stuff dynamically.
Maybe you want to check out some of the hello world code?
You can't build apps in XML. You use XML to define the UI and a few other things, but the logic of the app itself has to be written in Java.
Android development is in Java, but when you declare the layouts (where the buttons and so are going to be on the screen) you do that in XML.
So you have to use BOTH anyways.
XML for layout
JAVA for programming your app