13,048,846 members (68,749 online)
Forgot your password?
Sign in with
Chapters and Sections
Article Help Forum
Submit an article or tip
Post your Blog
Ask a Question
View Unanswered Questions
View All Questions...
All Message Boards...
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Design and Architecture
C / C++ / MFC
ATL / WTL / STL
Objective-C and Swift
Hardware & Devices
Hosting and Servers
Silverlight / WPF
Site Bugs / Suggestions
Spam and Abuse Watch
The Insider Newsletter
The Daily Build Newsletter
Most Valuable Professionals
The Insider News
The Weird & The Wonderful
General Indian Topics
General Chinese Topics
What is 'CodeProject'?
Ask a Question
Bugs and Suggestions
Article Help Forum
Advertise with us
About our Advertising
Comments by Mike Barthold (Top 14 by date)
You can return START_STICKY in the onStartCommand of your service. We use that in our SIP app too.
Keep in mind, your service has no UI --- u simply can not force android to keep your activities alive.
But you can keep your service alive.
So choose your architecture in a way, that your critical tasks that need to be up are part of the sticky service.
You have to consider several things here:
- Android 6+ in doze mode shuts down network. If you need to be reachable from outside (like incoming sip calls) use push notifications.
- you can *not* communicate to the internet at 24/7 in android if the device is unplugged from power source. doze/deep sleep wins. accept it and plan your app accordingly.
- the device wakes up after 2 hours of deep sleep for a small maintenance window - you get some seconds cpu time then before it sleeps again. next maintenance window is more than 2 hours, the next even more... and so on, until the user turns the screen on. the USER - not a program part that just sets a wake lock.
What is the hardcoded margin of -500dp?
This is not a very good design - always think relative, do alignParentTop or something similar.
Take that -500 out - I am very sure, you just have a different resolution on your physical device than on the preview screen and therefore the button somehow falls off the screen.
That hint might come late - but always have a backup of your keystore OFFLINE (on a usb stick for instance) that is kept secure and far away of all OS-updates, file system changes, IDE updates, etc.
With this you can always get your "original" keystore back.
Unfortunately this will not help in your situation, because you'd have restored your keystore already if you had such a backup.
Richard Deeming is right. You can't.
Would make all keystores and security completely obsolete if you would be able to reinitialize a keystore with a new password without telling the old one first.
if proguard is used right, it obfuscates your apk, so all your classes and methods are named like a.aa.aba.a(x,xx,xzzx) and no one can read it.
Also release-sign your apk with a keystore and private key. You need to do that anyway before you can put your app to the play store.
Please follow the guidelines by Google.
Tesseract is the most widely used OCR software. Yes you have to compile it yourself but it is very very powerful (even Google uses it, as far as I know).
Beside my approach of using an Asyntask below, I'd like to add that you are maybe just missing a .runOnUIThread call?
Looks to me as you have messed up some things in threading. What does the constructor of IceCream do? any UI/Handler/Message related stuff that needs to run in the UI thread?
Instanciate it in UI thread.
I hope I got it right :)
Sorry, answering questions with xml content messed my answer up... the two xml files are corrupted.
in the first xml block (the progress dialog), this code is missing:
<textview android:id="@+id/simple_progresstext" android:layout_width="match_parent" android:layout_height="match_parent" android:gravity="center" android:textcolor="@android:color/black" android:textappearance="@android:style/TextAppearance.Small" android:text="Working...">
in the second block, only the closing tag is missing
This looks like what I have been searching for - onTaskRemoved - didn't know the manifest flag so far - thank you very much!
Thanks for the quick reply :)
Unfortunately onDestroy on the Main activity does not help - it even gets called whenever Android thinks, it needs resources.
I need the point, where the "user" takes a "conscious action" of killing the app *now*.
I am not really sure, if this is possible in a way the product owners want it.
Why jdk8_65 and not 66? (Not, that it matters for your driver problem - just curious).
@Driver - Have you tried downloading the "original" directly from intel's website?
One thing you can try is to check whether there are problems with other intel-services on your machine:
type win+r (run) - "msconfig" go to the "services" tab, click "hide all microsoft services" to have a shorter list and then look for the "Intel(R) dynamic application loader host interface service" - clear the checkbox from this service.
Reboot your machine and try to re-install - it worked for me.
(I had not exact your error message, but i DID have problems installing HAXM - so maybe diabling this service might help you as well).
My machine works without any noticable differences, whether this service is enabled or not.
Reason for my vote of 5 \n Thanks! Good, sweet and short listing
Did you change the target framework to 4.6? Or still at 4.5?
Reason for my vote of 3 \n A bit deep into win32 api for my taste, as it is a matter of a few minutes with wcf/pipes or plain pipes in .net
even a localhost udp would be a matter of less than 20 lines of code if you do not want to use pipes for whatever reason (but that would let the local firewall popup a dialog so it's not the way to go imho - users would ask what the program is sending... no need for that).
as a matter of compliance/code analysis -> microsoft recommended rules tell you to put those invoke declarations in a class named NativeMethods, SafeNativeMethods or UnsafeNativeMethods.
see rule CA1060 https://msdn.microsoft.com/en-us/library/ms182161.aspx
and the attributes assigned to those classes - so consider to place them properly.
Reason for my vote of 5 \n Good read - I agree with most of your statements.
I only would add that XML Comments that are only auto-generated (by GhostDoc for example) and not even grammar-correct can also be a mess if the developer has nothing more to say.
But even I try to comment 100% of the public visible properties for the sake of tooltips and intellisense. (And I *do* generate my wiki pages from the xml-comments so mine are often more content-intensive and contain all the <example> and <exception> tags and even <remarks> :)
But I have seen many bad examples for xml-doc too out there...
If you comment something, the DO IT RIGHT. not half-hearted.
Web02 | 2.8.170713.1 | Last Updated 1 Jan 1900
All Rights Reserved.
Terms of Service