Develop Reference

DJI WaypointActionType for CAMERA_FOCUS and CAMERA_ZOOM

The documentation online did not have these two actions (CAMERA_FOCUS and CAMERA_ZOOM). Could anyone tell me what parameters are acceptable for these actions? I'm assuming it would only work with the Inspire drones which is what I'm working with. Thank you.
Current documentation:
CAMERA_FOCUS and CAMERA_ZOOM available in SDK:

How the zoom function waypoint action basically works the same way as the setOpticalZoomFocalLength function in DJICamera.
You will need to calculate the focal length value to pass in base on the current lens you are using. The max and min focal length values you can find under getOpticalZoomSpec function.
More information on setOpticalZoomFocalLength in DJI android sdk api:
https://developer.dji.com/mobile-sdk/documentation/cn/faq/cn/api-reference/android-api/Components/Camera/DJICamera.html#djicamera_camerasettings_setopticalzoomfocallength_inline
Hope that helps.

Not really sure what is your meaning.
I guess you want to know how to control camera focus/zoom using DJI MSDK? refer to their class reference and call the corresponding function. EZ as ABC
https://developer.dji.com/cn/mobile-sdk/documentation/faq/cn/api-reference/android-api/Components/Camera/DJICamera.html

There are a few more missing. I see the following (including the ones you mention):
CAMERA_ZOOM(7),
CAMERA_FOCUS(8),
FINE_TUNE_GIMBAL_PITCH(16),
RESET_GIMBAL_YAW(17);
I'll see what I can find out and get back to you.

DJI got back to me the other day, apparently these values are inactive currently, they do nothing in the current release but it's possible that a future release will include the functionality.
No date, version or timeline was indicated on when they might work.
For now, ignore them, they will likely be removed in the next update.

How to block Android app from being drawn on top of it? (Avoid Cloack&Dagger attacks)

Is there any way to tell my Android app that do not accept outside app content being drawn on top of it? Overlays,... (but of course accept application generated overlays, diglogs, toasts,...).
Specifically to avoid the kind of attacks such as Cloack and Dagger:
http://thehackernews.com/2017/05/android-hacking-technique.html?m=1
http://cloak-and-dagger.org/#Demos
Do full-screen and video apps fully avoid it? And if do, how do they do?

Set filterTouchesWhenObscured to true. Or implement the method onFilterTouchEventForSecurity().
More info here: https://blog.devknox.io/tapjacking-android-prevent/

How to find out a default behavior/value for an Android API?

I am learning Android programming, this seems to be a silly question.
pd = new ProgressDialog(this);
pd.setCancelable(false);
Cancelable can be
true
false
default behavior / not set
Is there an easy way to know the default behavior is either true or false?
In android Studio editor, use ctrl + Q, got this:
Online reference does not help either. setCancelable
I can run the code, then know the result, but it gotta be a easy way, right?

Take a look into its parent class: Dialog.
You can find out this line
/**
* This field should be made private, so it is hidden from the SDK.
* {#hide}
*/
protected boolean mCancelable = true;
By the way ProgressDialog it's not recommend by Google. You should use ProgressBar instead. You have to handle block button or something like this while ProgressBar is showing, but it bring user a better UX

You can control + click (on Android Studio or Eclipse) on the class that interests you and see on the library's source whether the boolean flag is set upon initialization on the class.

Usually, the information would be on the online reference. However, as you point out, it isn't!
Whenever I find I need to know something like that, and it isn't documented, then I check the source code. It is usually quite trivial to search for the specific class source in Google.
This of course, is only showing the value it takes by default for Android 4.4. In this case though, the value is unlikely to have a changed default. You should always bear that possibility in mind.

How to include suggestions in Android Keyboard

I am working on Android SoftKeyboard. I've created layout for keyboard but dont't know how to include suggestions which appears if we type some word in EditText.
For example if i write "Kn" then "Known" and "Known" are shown in Suggestions.
So my questions are -
1) How to include suggestions in Android Softkeyboard?
2) Is there any way to include our own list of suggestions?
Thanx a lot in advance.
I've already checked this and this but not able to find any proper answer. Any help would be appreciated.
EDIT
I want to include suggestions directly above Keyboard as shown in picture below.

You can use the static method UserDictionary.Words.addWord(....): Link
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) {
// On JellyBean & above, you can provide a shortcut and an explicit Locale
UserDictionary.Words.addWord(this, "MadeUpWord", 10, "Mad", Locale.getDefault());
} else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.CUPCAKE) {
UserDictionary.Words.addWord(this, "MadeUpWord", 10, UserDictionary.Words.LOCALE_TYPE_CURRENT);
}
You will need to add this permission to your manifest:
<uses-permission android:name="android.permission.WRITE_USER_DICTIONARY"/>
Added words will appear in Settings > Language & input > Personal dictionary.
If you are implementing your own soft keyboard, I suggest you go through Creating an Input Method. The suggestions are usually shown in the Candidates View. By default, InputMethodService#onCreateCandidatesView() returns null. You should override this method to return your implementation of the suggestions bar.
Here's a sample project that implements the Candidates view: SoftKeyboard.
More info:
Word and phrase suggestions go in the candidates view. Info about how to create & populate it are in the sample project mentioned above.
As far as I know, the selection of what words/phrases to suggest is developer's responsibility. Android does not provide those for you. You will probably need a set of dictionaries - one for each language/locale you plan on supporting. You may also want to maintain a dictionary of user-specified words.
Android's default keyboard uses these: Link
If you download one of these, unpack it and open with a text editor:
dictionary=main:en,locale=en,description=English,date=1402373178,version=47
word=the,f=222,flags=,originalFreq=222
word=to,f=215,flags=,originalFreq=208
word=of,f=214,flags=,originalFreq=214
word=and,f=212,flags=,originalFreq=212
word=in,f=210,flags=,originalFreq=210
.... 165,635 more lines
As apparent, the frequency plays a pivotal role in determining the suitability of a word as a suggestion. You probably don't want to suggest tachometer when the user types ta. You probably do want to suggest take - frequency helps you there.
Autocorrection:
word=id,f=99,flags=,originalFreq=99
shortcut=I'd,f=whitelist
The flags indicate appropriateness:
word=goddamn,f=0,flags=offensive,originalFreq=62
Even if you decide to use these dictionaries, the code to parse them and obtain meaningful suggestions will have to come from you.
Two articles (both by Peter Kankowski) that talk about predictive text input & spelling correction:
Using DAWG for predictive text input
Using Ternary DAGs for Spelling Correction
CandidatesView:
The first thing you should know about the CandidatesView: it is optional. In fact, LatinIME (android's default soft keyboard) does not use it. Instead LatinIME has its own implementation - SuggestionStripView - which is similar. The default behavior of InputMethodService#onCreateCandidatesView() is to return null. If you choose to provide your own implementation, don't override this method.
You need to decide what your CandidatesView should look like. One possible implementation can be a HorizontalScrollView. After you evaluate your suggestions (for example, user start writing "as", and your suggestion-logic gives you a List<String> containing "has", "was", "assist", "ask", "asked", "asking", "assume"), create & add TextViews holding these strings to the HorizontalScrollView(LinearLayout). This way, user can scroll horizontally and choose the intended word by clicking on it.
It is up to you to decide whether to use the API or handle the CandidatesView yourself. If you want to use the API, override InputMetodService#onCreateCandidatesView(), inflate your custom layout, then return it. Hold a reference to it, so you can update it when required. To control CandidatesView's visibility, use the method setCandidatesViewShown(boolean).

If you are creating a custom keyboard, I suggest you go through Creating Input Method, there is a sample code that you can go over. CandidateView is probably what you are looking for. It is explained in the link above.
If you want to provide inline spell checker, you would want to check out Spellchecker framework
Hope this helps.

How to perform Redo Undo operation in EditText

I want to know is there any method or any link or tutorial to perform redo undo operation in Android edittext. If any one knows than please let me know.

Quick note on the Antti-Brax/Divers(Kidinov) solution. It works great, except if you try to use it with a TextView post-API 23, you'll run into problems, because guess-what, Google actually added a hidden UndoManager (android.content.UndoManager) and didn't document it or make it obvious it was there. But if you have a hard/bluetooth keyboard in Marshmallow or Nougat and hit ^Z or SHIFT-^Z, you'll get undo/redo.
The problem comes if you're already using Antti-Brax's class with an EditText, and you also hook it to ^Z and shift-^Z, you'll run into problems with anyone using a hard keyboard. Namely the ^Z will trigger BOTH the native and Antti-Brax's undo, leading to two undos simultaneously, which isn't good. And after a few of them, you'll probably get a Spannable out of bounds crash.
A possible solution I found is to subclass the TextView/TextEdit/whatever and intercept the undo/redo calls from the TextView so they don't run as follows:
#Override
public boolean onTextContextMenuItem(int id) {
int ID_UNDO, ID_REDO;
try {
ID_UNDO = android.R.id.undo;
ID_REDO = android.R.id.redo;
} catch (Resources.NotFoundException e) {
ID_UNDO = 16908338; // 0x1020032
ID_REDO = 16908339; // 0x1020033
}
return !((id == ID_UNDO) || (id == ID_REDO)) && super.onTextContextMenuItem(id);
}
Those magic id numbers were found here, and are used only as a backup if the android.R.id.undo values aren't found. (it also might be reasonable to assume that if the values aren't there the feature isn't there, but anyway...)
This is not the best solution because both undo trackers are still there and both are running in the background. But at least you won't trigger both of them simultaneously with ^Z. It's the best I could think to do until this gets officially documented and the getUndoManager() methods of TextView is no longer hidden...
Why they made a feature you can't turn off (or even know if it was there or not) "live" in released Android I can't say.
I just opened an issue on Android's issue tracker if anyone wants to follow this.

There is an implementation of undo/redo for Android EditText in
http://credentiality-android-scripting.googlecode.com/hg/android/ScriptingLayerForAndroid/src/com/googlecode/android_scripting/activity/ScriptEditor.java
The code works but does not handle configuration changes properly. I am working on a fix and will post here when it is complete.
My Google search was :-
android edittext onTextChanged undo

I know this is an old question, but as there is no accepted answer, and this is an issue I've tackled myself from many angles, I'd like to add my solution in case it helps anyone. My answer is probably most relevant to large (1,000words+) volumes of text editing apps that require this feature.
The simplest way to resolve this problem is to make periodic copies of all text on screen, save it to an array and call setText() every time the Undo method is called. This makes for a reliable system, but it isn't ideal for large (i.e. 1,000words+) text editing apps. This is because it:
Is wasteful. It could be that only one word changes in a two thousand word document, so that's one thousand, nine hundred and ninety nine words needlessly committed to memory.
Can lead to performance issues, as some low-tier hardware struggles with rendering large amounts of text. On some of my test devices, this method can lead to freezes of a few seconds whenever Undo is called.
The solution I currently use is comparatively complex, but I've published the results in a library here.
Essentially, this library saves a copy of text as soon as a user begins typing, and then another copy of text once they've stopped typing for a set amount of time (in my case, two seconds). The two text strings are then compared, and the altered section of text returned, the indexes where the alterations occured, and details on whether or not the change was an addition of new text, a deletion, or a replacement of old text with new text.
The net result is that only the necessary text is saved, and when Undo is called, there is only a local delete(), replace() or insert() call, which makes for much faster operations on large text fields.

Here is the undo/redo implementation that was linked to from Gary Phillips' answer extracted into a reusable and universal undo/redo plugin for any widget that descends from a TextView. I added some code for persisting the undo history.
http://code.google.com/p/android/issues/detail?id=6458#c123
Hope this helps.

To preserve EditText Styling with regards to undo:
You can create an ArrayList<EditText> or ArrayList<String> (String containing html text) to store your last 10 (for example) actions. So ArrayList [0] would contain html text from your first action and ArrayList [9] would contain html text from your very last action. Each time the user taps "undo" in your app, you would apply ArrayList [size()-1] to your EditText and then remove ArrayList [size()-1] from your Array.