Posts tagged Android
How Fake Camera works
14After recent Kik update I have full mailbox of messages like „Fix fake camera asap“ and a lot of one stars ratings at Google Play. So let’s have a look into how Fake Camera works and how Kik/Android camera works – to explain, why I am unable to do anything with this.
Do you think Fake Camera is that „Camera picker dialog“ which appears after you chose to take a picture? Wrong! That’s Android system dialog!! Take a look what happens, when application (like old version of Kik) asks for taking a picture. There are two possible scenarios: there is just one camera application on your phone (or some of you cameras is set as default) OR there are more camera applications on your phone. Let’s draw a simple diagram of communication between application and android phone – for both of those cases.
In case one application (for example old version of Kik) asks for taking a picture, so phone answers with just one camera application and runs it for Kik. Let’s say it opens your phone default camera application directly.
In the second case, when there are more camera applications to chose, phone displays dialog – camera picker and lets user choose which camera application use. And runs it for him again.
Can you see that? That dialog is not displayed by Fake Camera application, but by your Android phone itself! Fake camera is just another camera application within that list!!!
Now let’s see how all this work with new Kik update: this new update has its own (in-application) camera, so it does not call external camera application for taking pictures. It just takes a picture within that application and does not say anything to Phone nor other application.
Again – can you see that? There is no way to let your Android phone to display that Camera picker dialog, because all that stuff does application itself (Kik). And because there is no way your phone can display that dialog, there is no way to run Fake camera (that gallery picker) nor any other Camera application. Deal with that or write a message to Kik (or whatever application you want to use) authors and not me, I have nothing to do with this!! And of course – if you changed your rating of Fake Camera because of this, put it back please, because Fake camera still works correctly!!
PS if you are still unable to deal with that, take the MinusIQ pill and go chatting to g+ page, if there is some place between animated gifs and selfies.
Glass hackathon Brno 2014
0Přestože jsem se spolupodílel na organizaci této akce, nebudu psát o slastech a strastech organizování, ale o tématu, které se přímo týká kódování a docela nepříjemně mě na této akci spálilo. Totiž o googlovském (dá se říci) házení klacků early adopterům a vývojářům pod nohy (hateposty dneska frčí, musím se trendu chytit!).
Spolčil jsem se s Radkem Bartoňem z Trinerdisu, protože jsem měl náladu stvořit nějaký backend, více než drátovat pro brýle. Radek přišel s nápadem čtečky ebooků ne nepodobnou Spritzu, na který mě shodou okolností nedávno odkázal jeden známý. Idea byla taková, že uživatel na telefonu vybere knížku a nechá si ji poslat do brýlí. Tudíž nějaký „push to device“. Pojďme se podívat na možnosti, které pro tuto funkcionalitu připadají v úvahu.

Glglglass
Nejjednodušší možností je využít Mirror API a intent filter. Pomocí Mirror API se pushne na timeline speciální karta, která obsahuje volání URI definované ve výše zmíněném intent filteru. Pěkný příklad použití je uveden v jedné odpovědi na Stack overflow.
Možností druhou je Google Cloud Messaging. Ten nabízí metody pushování notifikací dvě: pomocí HTTP a XMPP. HTTP volání je čistě synchronní, což vyplývá z podstaty protokolu – z mé aplikace (serveru) pošlu zprávu serverům GCM a čekám na odpověď o přijetí, což mě blokuje ve snaze odeslat zprávu další. Naproti tomu XMPP využívá GCM server jako broker, do kterého pere zprávy a odpovědi může až dodatečně (na základě id) vyhodnotit. Z toho je jasné, že pomocí HTTP je možné komunikovat pouze ve směru server->cloud->zařízení, kdežto v případě XMPP je díky držení otevřeného spojení možná obousměrná komunikace.
Protože byl na hákování vyhrazen celý den, zvolil jsem možnost b) Google Cloud Messaging a sice s využitím XMPP, abych neudělal během pěti minut servlet pro Mirror API a pak celý den jen neseděl a nekroutil palcama. Mimo jiné by potom bylo možné tento stejný přístup použít i pro mobilní aplikaci, která pushnutí iniciuje. Dokumentace je přehledná, dokonce je její součástí celý zdroják pro navázání komunikace s GCM. Existují i nějaké další poměrně detailní tutoriály. Kámen úrazu byl, že jsem (už po několikáté) přehlédnul nenápadný řádek „Note: To try out this feature, sign up using this form,“ takže jsem se nemálo divil odpovědi „Project 858xyz396 not whitelisted.“ Až po chvíli jsem daný formulář našel a zaregistroval do něj náš projekt pro hackathon. Bohužel, není to jenom robotem schvalovaná registrace, takže „lefuq“, zabil jsem spoustu času, tohle je jen pro vyvolené, až mi to někdy někdo schválí.
Po obědě jsem se pustil do GCM pomocí HTTP. Ovšem opět jsem to nedotáhl do konce, protože záhy mi Radek hlásí, že brýle nepodporují Google Play Services. To je teda fail, srsly, na co ty brejle jsou, opravdu jen na to pushování karet pomocí Mirror API? Nebo opět pouze pro vyvolené (to by mě zajímalo, kdo to je, když vývojáři zaplatili nemalé peníze za samotné pitomé brýle)?
Takže nakonec nouzovka v podobě jednoduchého REST rozhraní, kdy si brýle samy tahají seznam a odpovídající knížky. Škoda, teď by se hodil další den hackathonu, kdy bychom přidali to pushování pomocí Mirror API a k tomu appku pro telefon s tydlidrojdem (nebo tlačítko do prohlížeče – na pushnutí článku k pozdějšímu přečtení).
Poučení na závěr: důvěřuj, ale prověřuj se ve spojitosti s Googlem mění na: nedůvěřuj, ale prověř, neuvěř a radši to udělej jinak. Každopádně aspoň nějakým výstupem je zdroják k „serveru“ na GitHubu a běžící endpoint na OpenShiftu. Tak alespoň něco, mimo akce samotné a následných škopků.
Howto clear defaults to get Fake Camera running again
43Quick note: please use Google plus community for asking a questions.
I like to read reviews of my applications on Google Play, especially those with suggestions and questions :). Last few days I’m getting more and more questions like this one for Fake Camera
Won’t open on kik When I tried to send a pic as a live pic from the gallery it took me to the regular camera and didn’t give me the option to choose the app or the regular camera.
or this one
Fake Camera does not work for me, you sucks!
So because of that I’m going to write a step by step how to clear defaults and let camera picker appear again, because that is the main reason of those problems. We’ll start quickly, I just want to say following at the beginning: If this work for you, don’t forget to change your rating and review on Google Play!!!!
If you accidentally selected „Use as default“ checkbox in Camera picker, it’s possible to revert this, Just follow these steps:
And now comes the tricky part: in application list select that app, which opens automatically instead of camera picker, in my case it’s standard Camera app:
And we are done for now, camera picker dialog should appear instead of default selected application. Please note that this has nothing to do with inapp camera some applications may use – that’s impossible to fake.
One more time – if your Fake Camera works again, don’t forget to change your rating and review on Google Play, thank you! And, of course, if you’d like to say thanks for Fake Camera, just buy a Donate Version, or send me some bitcoins or so. Thank you!
Howto access recent query suggestions on Android and populate ListView with them
0I’m working on search activity for Beermapa and because I did not find any topic covering reading access to SearchRecentSuggestions and I needed to load saved suggestions and fill a ListView with them, so I did some research and wrote this post.
What I want to achieve is an input for writing search query, which displays custom suggestions (based on searching query) and also ListView placed right under input box, which displays recent search queries.
My first try was with EditText and TextWatcher, which after each written character filtered my listAdapter backing ListView, something like this:
searchEditText.addTextChangedListener(new TextWatcher() { public void afterTextChanged(Editable s) {} public void beforeTextChanged(CharSequence s, int start, int count, int after) {} public void onTextChanged(CharSequence s, int start, int before, int count) { adapter.getFilter().filter(s); } });
But since Android has pretty good Search Interface, I was wondering how to use it with my search (because of possible future use of voice search etc.). Adding recent query suggestion is described in tutorial, also custom suggestion is. But there is nothing about how to access saved queries another way then in SearchView whispering box. Saving is really easy:
SearchRecentSuggestions suggestions = new SearchRecentSuggestions(getApplicationContext(), MySuggestionProvider.AUTHORITY, MySuggestionProvider.MODE); suggestions.saveRecentQuery(query, null);
First solution which came on my mind was to implement own saveRecentQuery routine, which saves last queries to local database, but that’s not the way – why to write already written code again?
Finally – there is possibility to access those saved queries through ContentResolver, which returns Cursor:
ContentResolver contentResolver = getApplicationContext().getContentResolver(); String contentUri = "content://" + MySuggestionProvider.AUTHORITY + '/' + SearchManager.SUGGEST_URI_PATH_QUERY; Uri uri = Uri.parse(uriStr); Cursor cursor = contentResolver.query(uri, null, null, new String[] { query }, null);
Where query is String representing searching query, or null for returning all records. Now with received cursor it’s simple to populate ListView:
cursor.moveToFirst(); String[] columns = new String[] { SearchManager.SUGGEST_COLUMN_TEXT_1 }; int[] views = new int[] { R.id.name }; ListAdapter listAdapter = new SimpleCursorAdapter(this, R.layout.component_pub_row, cursor, columns, views, 0); listView.setAdapter(listAdapter);
Note that last parameter in SimpleCursorAdapter – it’s there because of deprecation of constructor with FLAG_AUTO_REQUERY, for more details see this Stack Overflow topic.
Verzování a testování Android aplikací
1Vrátil jsem se nedávno k jedné odložené aplikaci a začínám ji křísit s novými nápady a s trochu změněným konceptem (s detaily přijdu v brzké budoucnosti) a protože jsem se dostal k potřebě aplikaci testovat ve více lidech, kdy někteří mají ne zrovna aktuální verzi buildu a přesto reportují chyby, začal jsem používat systém číslování verzí, který bych chtěl tímto postem popsat.
Problém je následující: vypustím testovací verzi mezi testery a mezitím vývoj nezamrznu, ale pokračuju v opravách, úpravách a (přiznám se k tomu) někdy i nových featurách. Často se stane, že tester pošle stacktrace starší verze, nebo přijde aktuální verze, jenomže po úpravách už nesedí čísla řádků, či díky refactoru je daný fragment někde úplně jinde a podobně. Jak teda zkontrolovat, jestli už chyba byla odstraněna, nebo tam je pořád? Poměrně jednoduše, stačí pár nástrojů.
Celý řetězec sestává z IDE Eclipse, Pivotal Trackeru, PT-mylyn connectoru a nějakého systému zprávy verzí (používám Git na Bitbucketu). Základem je si navyknout odklepávat aktivní tasky zadané pomocí Pivotal Trackeru v Mylynu, měnit odpovídající čísla patchů v Manifestu a commity provádět s daným identifikátorem (ideálně do vlastního branche, který se po release zmerguje, ale kdo by se s tím sr…l, žejo :)). Pojďme ale postupně, ukážu to na konkrétním příkladě – tasku. (Pozn. používaná skladba číslování verzí vychází z následujícího schématu, uvedeného např. na wikipedii).
Veškeré změny, požadavky a bugy zadávám pouze skrze Pivotal Tracker (nebudu tu rozebírat nástroj samotný, ani jak iteruju – to je každého věc :)). Důležité je, že každá story má jednoznačný identifikátor, jak je vidět na následujícím screenshotu.
V Eclipse mám PT napojený skrze mylyn-connector (návod jak na to je přímo na stránkách projektu) na Task list, kdy pracuju na aktuální vybrané úloze. Na následujícím screenshotu už je story finishnutá, takže je přeškrtnutá.
Když potom dané změny commitnu, nechávám jako title dané změny identifikátor a popisek, který je v PT – při commitu jsou už automaticky předvyplněné. V přehledu verzovadla je potom jednak vidět interní identifikátor daného commitu, ale v rámci popisku i identifikátor z PT.
A teď ono celkové propojení: když aktivuju task v IDE, změním daným identifikátorem z PT i build verzi v manifestu, společně s versionCode.
Když tedy následně distribuuju danou verzi testerům, tak je možné v rámci vlastností aplikace přehledně zkontrolovat verzi, kterou testují.
A pokud někdo nahlásí chybu, o které si nejsem jistý, zda byla opravená, jednoduše se vrátím ke konkrétní verzi z repozitáře a můžu zkontrolovat, o co vlastně šlo a případně si zadat novou story (bug by mohl být zadán číslem revize a build verze se neměnit).
Je mi jasné, že asi znovuobjevuju kolo, ale připadlo mi to celé tak geniálně jednoduché a praktické, že mi nedalo se o to nepodělit. Také mi nedá se nepodělit o očekávání testovacího frameworku Testflight pro Android. Věřím, že předchozí tipy skvěle doplní a posune na ještě vyšší level!