I had read the .dex format document on Google, but I still got some confuses with some layer.
link_size & link_off : Google said it left unspecified and then said it's hook for runtime, so what it is? The static hook for global or local? or the hook to native library?
map_off : Why it need this redundancy IDs list? is it some kinda like the file address table?
proto_size & proto_off : Not quite sure what it actually is. I had de-assembled an randomly picked dex and look on this section, this section contained some short sign like DD/LL/JLJJ/...brabrabra, that made me more confused about this section. What exactly this section doing for?
Can anyone enlighten me?
The link section has never been specified or used. You might run across some dex files that have a garbage value for these fields, as an attempt to prevent baksmali from being able to be run on them (due to an old bug, that has been fixed for a while).
For the map item, Yes, there is redundancy for the locations of the indexed item sections - the location for these are specified in both the header item and the map item. But the map item is the only place the locations of the offset item sections are specified (the variable size items in the data section)
The prototype section defines the prototype for a method, i.e. the parameters and return type. If you look in the method_id_item, you'll see that it has a reference to a prototype item.
Related
I realized that when calling "createFile", it creates a new file even if its title is an already existing title.
What am doing now is to search for the file first and if i can't find it, i create it. Two methods for a simple problem.
There is a better way to create a file overriding it if already it exists?
Google Drive is actually a 'flat' model, where every object is identified by it's unique ID.
So, when an object (file/folder) is created, it gets a unique ID. The object may/not have content. Everything else is 'metadata'. The tree structure of popular OSs is actually 'faked' by metadata links (parent links). That means in Google Drive you may have multiple children with the same metadata (title/name) in a parent object. And you may also have multiple parents for any child object (single object appears in multiple parents' folders).
All this rant means one thing for your situation:
Once you create a file/folder and get hold of it's ID, 'creation of a new file with the same name' can be accomplished by modifying it's content and/or metadata (you can see a typical example here).
If you take the path of delete/create (which is also possible, but had not been until recently), you are actually:
1/ modifying the original file/folder's 'trashed/deleted' metadata
2/ creating a brand new object with a different ID
Think twice before you select the method you use. UPDATE method is a 'one-step', approach preferable in async environment (create MUST wait for successful delete). On the other hand, if you use DELETE/CREATE approach you may be able to take advantage of the fact that 'trashed' object will be around for a while.
Good Luck
I think files are uniquely identified by their ID in the Drive API. Therefore you have no way to control for the title using the drive API itself. So doing it yourself is probably the way to go.
EDIT: The ID is what is important with all that synchronisation happening. A title could change easily therefore using it as a unique identifier would be a bad idea. Hence the unique ID.
What you could do if the file already exists is either remove it and replace it by the new one (bad idea I would say) or simply add an extra number at the end of the new file that will be added to the folder.
There are some questions about naming id in xml layout.
If i have a Activity used to create student.
What is the most suitable id for the EditText of student name?
et_student_name
et_name
et_create_student_name
I always use 3, because it is relate to the class name.But sometimes i think it is too long. I want to use 2 / 3, it is shorter but i am afraid it will repeated with other xml.
What is the good naming for the id?
Is it not good on repeated id in different xml layout?
Waiting for Help,
Thank you.
First, unless you are creating a distributed "jar" or "SDK" then you will discover name conflicts at build time. Worry about it then, not now. You are spending more time trying to avoid the problem than it's worth. Sometimes you need to prevent problems, but this isn't one of them.
If you are still worried, then there are 2 prefixes you can consider using. First, add a prefix that is somewhat descriptive of the XML file that has the element. For example, if the XML file is called "create_student.xml" then add "cs_" as the element for the prefix. (FYI - This really sucks when you change the filename, but that rarely happens.)
Second, add a prefix (or another prefix) for the package/class you are targeting. This prevents duplicates for SDK's and other libraries that may end in another developer's build. For example, if your SDK is "Student Registration and Identification" then add "sri_" to each element in the package.
The rest of the name is solely up to you. Having "et_" in the name for an EditText is helpful, the rest is going to be either "too long" or "not enough" almost every time.
to add to #AjayP.Prajapati your ids should not be the same as java keywords like break,continue ,switch,for etc..., and also your ids do not need to be special. if you have repeated ids the first occurrence will be returned.
I am doing direct queries to wikipedia's website via an android app.
However, sometimes when I get "REDIRECT" queries, and my redirect suggestion has a # sign in it, I don't really know how to handle it. I know I can just throw everything out past the # sign, but that means I'm looking up something that is relatively unimportant.
Here is an example link;
http://en.wikipedia.org/w/api.php?action=query&prop=extracts&titles=Poof_(The_Fairly_OddParents)&format=json
I can just redirect to List_of_The_Fairly_OddParents_characters, but I want to know if there is anything useful I can do with the "#Poof" because I'm sure that the information is there for a reason.
I could not find anything on MediaWiki APIs.
Please help!
Thanks
Most of the time the part after the hash is a section title (though it is simply appended to the new URL, so it can be, and occasionally is, used to point to other kinds of anchors), so you can locate the section (with the mobileview action for example) and with the section index you can query the HTML for that section. (extracts does not support sections, so you you must use something else and enforce length limits manually.)
The hash points to a named anchor or ID in the target document. So if you're parsing the page content, then ideally you'd find the anchor tag or ID and return the content that follows that element, rather than starting at the beginning of the content.
I'm trying to build a complex form where almost all of the elements are optional. It starts with just a single field and an "add element" button. When you click add, the form shows a Spinner of the types of elements you can add to the form (location, photo, detailed note, timestamp other than "now", etc). When you select an item, it will launch an Activity, and each item has a different associated Activity.
In addition, each choice will have several bits of data, which it would be nice to store "with" the Activity somehow:
An icon and the displayed name in the Spinner
A key for storing the data in the db (as well as passing to a webservice)
A layout for how to display the result on the original form (i.e. a thumbnail for the photo, the lat/lon for the location, etc)
I was considering a set of classes that all extend an abstract FormElement class, and would have static elements for each of the above extra pieces of data. (An additional bump for this solution is how much of a pain Resources are in a static context.)
How can I make this as clean and maintainable as possible? I'd really not enjoy editing five different files to add a new type of element to this form. (Mostly because I can guarantee I'll miss one and spend hours chasing down unbugs.)
A few tips...
Unit tests will prevent "unbugs" :)
When each Activity has obtained the information it needs from the user, call Activity#setResult() with an Intent that contains your per-type data. Intent supports all the Bundle methods, so you can set different types of data as needed.
To support #2, make sure you're using Activity#startActivityForResult(Intent,int) to launch it, and listen for the result in Activity#onActivityResult(int,Intent)
I would probably maintain the list of available "element" types for use with the SpinnerAdapter (e.g., ArrayList<Class<? extends AbstractFormElement>>, and invoke static methods like .getDisplayName(), .getActivityClass(), etc, in the Adapter's getView() method, in order to determine what to display and what Activity to launch.
In this way, your list would actually contain things like { MyPhotoElement.class, MyTextElement.class, MyDateElement.class, ...}).
As each element is added to the form, add it to an ArrayList<AbstractFormElement>, which will be used to back another Adapter for a ListView. That adapter will dispatch the inflation of a custom view layout, as well as the creation of a ViewHolder, based on what type of object it is -- that will require that each distinct AbstractFormElement will have its own "view type", according to the Adapter. See BaseAdapter#getItemViewType(int) and related getViewTypeCount().
It's worth noting that these will need distinct view types only if one cannot be converted to the other... For example, if you have two "Elements" that only need to display a string of text in the list, those can both share a "text-only" view type. Likewise, two elements that only display a photo, or can easily convert one to the other (e.g., an icon with a caption, vs a photo thumbnail with no caption), can share a single "image-plus-caption" view type.
With the above in mind, you actually would end up having to modify different files to add a new type (well, I guess technically you could have them all in one file, as inner classes, but there's really no good argument for doing that), but if you've done your interface API correctly, and follow good OO practices, and implement good unit tests, you'll considerably reduce the amount of effort required to find bugs -- simply because most of the things involved in adding a new type would actually force a compiler error if you do it incorrectly. Add to that the fact that a proper unit test suite will be able to programmatically add all possible types, and ensure that everything displays properly, and you should have a pretty streamlined process for easy extensibility :)
It sounds like a lot of work, and it might seem tedious and verbose at first... But the end result is actually much more maintainable, especially if your list of element types is going to be fairly extensive.
What are some layout file naming conventions people have come up with.
I haven't found anything online, but thought about using the following convention.
What does everyone think?
- activity_*
- dialog_*
- list_item_*
That's all I have worked with so far.
Also, what about the naming of the activity against its layout? For example:
-> res
-> layout
-> activity_about_us.xml
-> src
-> activity
-> AboutUs.java
Strangely enough, trying to google this question brings only this page as meaningful result...
For the past half year I am using naming convention similar to yours but with shorter prefixes. For example:
For activity that shows "About us" screen:
Class name: ActAboutUs. Prefixing class is kind of overkill but it clearly distinguishes activity classes from the others. Initially I used separate directory for all the activities (similar to your approach) but after some time I realized that for bigger apps may be it is better to group in directories by feature than by superclass (i.e. Activity). It is easier for me to work in single directory for example /src/settings/ when I work on Settings. That way all java files that I need are in a single dir so i don't have to wander around:
/src/settings/ActSettingsGlobal.java
/src/settings/ActSettingsNet.java
/src/settings/Settings.java
/src/settings/SettingsDBAdapter.java
/src/settings/etc...
This approach also helps to split the work among different developers, i.e. each one is working in his own dir on separate feature so no stepping on each other's feet :-).
Some people preffer suffixes but I found them less useful. Prefixes help to group things alphabetically like in the example above: Act* prefix is sorted first so all activities are conveniently at the top.
I am even considering of using Act_ as a prefix which is more readable although it is in conflict with java naming conventions...
Layout filename: act_about_us.xml. In res/layout/ we don't have the "luxury" of subdirs which is quite unfortunate so the only way to group things is using appropriate prefix like act_, dlg_, etc...
String IDs: <string name="act_about_us_dlg_help1_title" ...
string.xml is the place where we have most problems with duplicate names. It is very easy to create duplicates if naming convention like activity_element_item is not used. It adds a lot of additional typing but it saves you from a lot of confusion later on.
For global (application wide) strings we use prefix "global_", for example global_btn_ok, global_msg_no_inet_conn. Usually we make one person responsible for all global_ strings so if someone needs new string or change he needs to sync with him in order to avoid creating a mess.
(now I am realizing that activity__element__item (two underscores) is more clear and readable than activity_element_item)
All in all I still can't get rid of the feeling that there is something wrong with my approach because I can't believe that google devs created such an inconvenient framework when it comes to working with files, IDs, names, etc...
i think following naming convention should be follow
for activity
if our activity name is
DisplayListActivity
then our layoutname should be
display_list_activity.xml
for list items we can include category in list item layout name
country_list_item.xml
and for dialogboxes their action can be included
delete_country_dialog.xml
When looking for a group of layouts, which is how I tend to work on them, I find it effective to always prepend the class name and follow up with any sub-layouts. For Instance:
Class Name: AboutActivity.java
Layout Name: about_activity.xml
Sub-layout Name: about_activity_menu.xml
Sub Sub-layout Name: about_activity_menu_item.xml
Your activity will always be at the top of each grouping and hunting for non-activities becomes less of a chore. Anyone know why sub-folders aren't a thing yet? I expect for efficiency and simplicity on the back-end, but I imagine it wouldn't hurt too much.
This is a good read https://jeroenmols.com/blog/2016/03/07/resourcenaming/
Basically, you follow WHAT WHERE DESCRIPTION SIZE
For example, layout file
activity_main: content view of the MainActivity
fragment_articledetail: view for the ArticleDetailFragment
strings
articledetail_title: title of ArticleDetailFragment
feedback_explanation: feedback explanation in FeedbackFragment
drawable
- all_infoicon_large: large version of generic info icon
- all_infoicon_24dp: 24dp version of generic info icon
The first part of a layout file name should always be the type of the corresponding class.
For example if we have a class MainActivity (type is Activity in this case), the corresponding layout file should be called activity_main.xml
That means that lets say we have a dialog called WarningDialog, the corresponding layout file should be called dialog_warning.xml, same goes for fragments etc.
This might seem familiar because thats also how the activity/layout files are named when creating a new project in Android Studio (MainActivity -> activity_main.xml).
For me, naming should fix two important requirements:
it should give you a hint about files' content and type (for example activity_login/login_activity or movie_list_item/list_item_movie)
it should visually group related items together to minimize jumping back and forth
For the second requirement, most people define "related" as type related which gives you something like this:
activity_login
activity_movie_list
activity_user_list
activity_settings
fragment_movie_list
fragment_user_list
item_movie
item_user
etc.
I prefer to do grouping by feature since you'll almost never work on all activities or all fragments, but instead, you'll work on movies feature or setting feature.
so, my prefered way is this:
login_activity
movie_list_activity
movie_list_fragment
movie_list_item
user_list_activity
user_list_fragment
user_list_item
settings_activity
Source files are following xml naming but in CamelCase, so there will be
LoginActivity
MovieListActivity
MovieFragment
etc.