Visual Studio - Task List

Visual studio je silný nástroj pre vývojára. Má množstvo funkcií, ktoré majú pomôcť vývojarovi v jeho práci. Jedna z takých funkcií je Zoznam úloh (Task list). Task list si treba zobraziť cez menu, ak nie je zobrazený:View\Other Windows\Task List.

Obr.1. Task List v strede na spodku Visual Studia

Task List je rozdelený na dve časti. Horná časť je rozbaľovací zoznam (Combobox), v ktorom máme kategórie, môžeme si zvoliť užívateľské úlohy (User Tasks) a komentáre (Commnets). Dolná časť je zoznam, v ktorom sa zobrazia buď komentáre, alebo užívateľské úlohy, podľa voľby rozbaľovacieho zoznamu.
Popíšem najprv komentáre. Funguje to jednoducho. Začnete riadkový komentár v zdrojovom kóde nejakého programovacieho jazyka ( Visual Basic, C#) za ním kľúčové slovo TODO, HACK alebo UNDONE. Za kľúčovým slovom použijeme výstižný komentár.
Každý komentár, v ktorom sa na začiatku zobrazí nejaké z uvedených kľúčových slov sa zobrazí v zozname Task List. Po dvojitom kliknutí na neakú položku v zozname Vás Visual Studio automaticky prenesie na riadok s príslušným komentárom.
Musím poznamenať, že ak sa niekomu nepáčia použité slová, môže si ich zmeniť, alebo k ním pridať nové. Vykonať sa to dá cez menu Tools\Options, element Enviroment\Task List. Vývojár môže buď zmeniť, pridať, alebo zmazať kľúčové slovo. Možnosti nastavení pre Task List sú jednoduché a nebudem ich tu rozoberať.

Ďalšia kategória sú User Task. Na pravej strane comboboxu po výbere kategórie User Tasks sa zobrazí  malé tlačítko, ktorým si môžeme pridávať úlohy do zoznamu a vyplnení popisu (Description). Po vykonaní úlohy ju môžeme buď vymazať zo zoznamu cez kontextové menu, alebo ju odfajknúť cez CheckBox, čo je na ľavej strane.

Visual Studio obsahuje množstvo funkcií, ktorými si vývojár dokáže uľahčiť prácu, keď pozná túto funkčnosť. Nabudúce poviem niečo o klávesových skratkách a ako si ich meniť.

Android Wear Developer Options

V nasledujúcich riadkoch sú opísané developer options pre android wear. Veľa týchto možností je rovnakých ako na mobilných a tabletových verziách android systému. O týchto možnostiach sa dá dočítať v predchádzajúcom článku: Android developer options.

Stay awake when charging - rovnaké ako na mobiloch, no need to comment.

Bluetooth Snoop Logging - toto je totožné s options v mobile, vytvorí log súbor, kde je zachytená všetká komunikácia s mobilom cez technológiu Bluetooth. Log súbor a jeho cesta: /sdcard/btsnoop_hci.log alebo cez env premennú $EXTERNAL_STORAGE/btsnoop_hci.log. Súbor je možné analyzovať pomocou programu Wireshark. Súbor sa pochopiteľne nachádza v zariadení a treba ho vytiahnuť pomocou Adb utility, ale to je pre technicky zdatnejších jedincov.

Vibrate on connectivity change - hodinky zavibrujú pri strate Bluetooth pripojenia s mobilom alebo zavibrujú pri obnovení spojenia. Neviem či je na všetkých typoch hodinkách rovnaký vzor vibrovania, no moje (MOTO 360 v1) zavibrujú raz a dlhšie pri strate spojenia s mobilom a pri obnovení spojenia zavibrujú dva krát krátko po sebe.

ADB debugging - no čo na to poviem, povolí spojenie ADB nástroja s hodinkami a umožní tak vývojárom svoju prácu a ladenie.

Location - o tomto som nenašiel viac informácií, ale odhadujem, že je to podobné voľbe pre mobily Allow moc locations.

Debug over Bluetooth - povoľuje ladenie aplikácií cez Bluetooth, tak že presmeruje aplikačný debugový výstup cez telefón, ktorý je pripojený k vývojovému počítaču. Viac info ohľadom pripojenia hodiniek je na následujúcom linku: Debugging over Bluetooth.

Wear Developer Options -> Force display burn-in protection - všetky oled displeje sú skvelé, ale majú veľkú nevýhodu. Možeme si vypáliť do nich obraz. Hlavne pre tých, čo majú zapnutý ambient screen. Ako ochrana pred vypálením je toto nastavenie. Nastavenie sa zapne až po reštartovaní hodiniek. Ako to vyzerá je v tomto videu: Huawei Watch: AW Burn In Prevention 4K Lapse [N5X].

Wear Developer Options -> Force low-bit ambient mode - zníži sa rozsah farieb používaný na hodinkách, farby sú limitované na čiernu, bielu, modrú, červenú, zelenú, cyanovú, mangenta a žltú. Slúži na šetrenie batérie, aby dlhšie vydržali hodinky.

Revoke debugging authorization - rovnaké ako na mobiloch.

Allow mock locations - pomocou tohto je možné manuálne nastaviť lokalizačné informácie. Na nastavenie falošnej lokalizácie je potrebné aplikáciu. Ale pred použitím aplikácie je nutné túto položku povoliť.

Debug layouts - s týmto som si zapol ohraničenia prvkov na obrazovke (rovnaké ako na mobile, pod názvom  Show layout bounds).

Debug overdraw - toto je rovnaké ako na mobiloch, len v skrátenej forme. Plné meno nastavenia v mobiloch je Debug GPU overdraw.

Debug GPU profiling - spraví grafickú vizualizáciu vykresľovania GPU, rovnaké ako v mobile.

Pointer location -  rovnaké ako v mobilnej verzii android systému, zobrazí v hornej časti obrazovky lištu s informáciami o dotyku a polohe dotyku. Má to malý problém, lišta nie je celá vidieť, hlavne na zariadeniach so zaokrúhlenou obrazovkou ako hodinky Motorola Moto 360.

Show touches - povolenie umožní zobrazovať vizualizáciu v mieste dotyku, aby užívateľ videl, že sa dotkol. Má sa správať rovnako ako na mobiloch. Narazil som na problém, že povolenie tejto možnosti nezobrazí vizualizáciu. Dlhším pátraním som nenašiel nič, viacero developerov na tento problém poukazovalo a je možné, že problém je iba špecifický pre Motorola Moto 360 s určitou verziou.

Bug report in menu - k tomuto nie je čo dodať, je to rovnaké ako v mobile. Chvíľu potrvá, kým sa report vygeneruje. Táto ponuka sa zobrazí v zozname aplikácií, teda v menu.

Automatic Wi-Fi toggle - automaticky zapína Wi-Fi, aj keď je pripojené k mobilu. Viac neviem zistiť. Malo zdokumentované.

Wi-Fi Verbose Logging - pomáha logovať viac informácií ohľadom Wi-Fi, v Logcat-e vidieť dodatočné informácie ohľadom Wi-Fi a uľahčuje odhaľovanie problémov.

Pri týchto posledných možnostiach som nanešťastie viac nezistil. Ak sa niekomu podarí zistiť viac, budem rád, keď to bude so mnou a ostatnými vývojármi zdieľať. Na záver dodám, že tieto možnosti sa vyskytujú pri Android wear komponentách verzie 1, verziu 2 doplním priebežne.

Battery optimization -

Wear Developer Options ->  Force software recognizer -

Wear Developer Options -> Audio Injector -

Firebase Cloud Messaging in Android

Firebase Cloud Messaging (FCM) je v podstate nová platforma na posielanie push správy. Nahrádza starý framework Google Cloud Messaging (GCM), ktorý je momentálne deprecated. Trochu som sa hral s FCM-kom a popravde, mi zo začiatku prišlo zložitejšie, keďže môžem posielať dva typy správ, a to: Notification message a Data message. Správy môžeme posielať troma spôsobmi, teda jednému zariadeniu, skupine zariadení alebo zariadení, ktoré sú subscribnuté na nejaký topic. FCM ponúka ešte jednu možnosť, ale tú som osobne neskúšal, keďže som sa ešte nestretol počas vývoja s takým use caseom, jedná sa o posielanie správ smerom od zariadenia na server. Bližšie introduction ponúka následujúci link: Firebase Cloud Messaging.

Pridanie Firebase Cloud Messaging-u do projektu

FCM má zmysel pre zariadenia verzie Android 2.3 a vyššie, je potrebné mať aj Google Play Services SDK  a minimálne Android Studio 1.5 alebo vyššie. Pri Google Play Services si treba dať ale pozor, spoločnosť Google oznámila, že prestane podporovať zariadenia Android verzie 2.3 a 3.0. To znamená, že Google Play Services verzie 10.2.0 už bude podporovať zariadenia s verzion 4.0 a vyššie, bližšie info: Google Play Services and Firebase for Android will support API level 14 at-minimum.

Pridať FCM je možné dvoma spôsobmi, a to manuálne alebo pomocou Assistant záložky v Android Studio. Použitie Assistanta neopíšem, pôjdem manuálnou cestou.

Ako prvé je nutné vytvoriť vo Firebase konzole projekt, viď. obrázok:

Firebase console - create new project

Po vyplnení mená projektu nám ukáže ďaľšiu obrazovku, kde môžeme pridať aplikáciu do projektu. Po zvolení pridania, nám zobrazí dialóg, ktorý nás prevedie všetkými potrebnými krokmi. Prvá obrazovka je:

Firebase console - dialóg pridanie aplikácie

V prvom dialógu pridania aplikácie je potrebné vyplniť package name aplikácie. Pozor, treba zadať presne a nepomýliťsa. Možné je aj dodať ďalšie voliteľné polia, viac sa o nich môžete dozvedieť tak v samotnom dialógu. Dialóg poskytuje nápovedu.

Firebase console - vygenerovania a stiahnutie config súboru

V tejto obrazovke nám dialóg vygeneruje config súbor a začne automatické sťahovanie(možno vyzve na potvrdenie začatia sťahovania v prehliadači, záleží od konkrétneho prehliadača a jeho nastavení) config súboru, ktorý má meno google-services.json. Ten si treba pridať do Android Studia projektu, veď návod už je v dialógu, stačí len čítať.

Firebase console - zakončenie dialógu a posledné úpravy v projekte Android Studia 

Následne je potrebné pridať niekoľko riadkov do build.gradlu ako je v poslednej časti dialógu. Keby nestačil návod v dialógu, alebo tento návod: Android firebase setup. Ako posledné je potrebné ešte pridať požadované dependencie: compile 'com.google.firebase:firebase-messaging:10.0.1' .

Editácia manifestu a zdrojákov

Pre ďalšiu prácu potrebujem pridať dve služby na projektu a definovať ich v manifeste. Vytvorím classu s menom MessagingService, kde extendnem triedu FirebaseMessagingService. To nám poslúži ako kostra na pridanie eventu, ktorý obslúži push message. Potom vytvorím druhú classu TokenGenerationService, kde extendnem triedu FirebaseInstanceIdService, ktorá ma na starosti generovanie tokenu, ktorý neskôr využijeme. V manifeste projektu treba definovať ešte dve služby, a to:

<service android:name=".MessagingService">
  <intent-filter>
     <action android:name="com.google.firebase.MESSAGING_EVENT"/>
  </intent-filter>
</service>

<service android:name=".TokenGenerationService">
  <intent-filter>
     <action android:name="com.google.firebase.INSTANCE_ID_EVENT"/>
  </intent-filter>
</service>

Položiek do manifestu súvisiacích s FCM je viacej, stačí sa obrátiť na tento zdroj Set Up a Firebase Cloud Messaging Client App on Android. Dve ďaľšie súvisia s nastaveniami defaultnej ikony pre notifikácie a farby prichádzajúcej notifikácie. Týmto sme urobili všetko potrebné a stačí nám úž len v doplniť potrebný kód do tried, ktoré sme vyššie uviedli. Ešte poznámku, že ak chceme používať vygenerovaný token, netreba zabúdať, že sa vygeneruje nanovo vždy počas určitých udalostí, ktoré nastanú v zariadení, Vo vyššie uvedenom linku sa dá dočítať počas akých udalosti sa generuje na novo token. Udalosť, kde ohandlujeme novo vygenerovaný token by mohla vyzerať takto:

public class TokenGenerationService extends FirebaseInstanceIdService {
@Override
public void onTokenRefresh() {
    super.onTokenRefresh();
    String refreshedToken = FirebaseInstanceId.getInstance().getToken();
    //tymto mozeme vidiet v logcat-e ako vypada token
    Log.d("BAGA", refreshedToken);

    /*
    token mozeme posielat na backend server aby som subscribol aplikaciu pre
    odber noviniek a posielanie upozorneni uzivatelom na zariadenia alebo mozem 

   uplne ignorovat token, to zalezi od use case-u
   */
 }

}


Posledná trieda má na starosti spracovanie push správ, ktoré prichádzaju v údalosti onMessageReceived. Než doplním  poslednú triedu, ktorá bude mať na starosti príjem push správy a vytvorenie notifikácie v zariadení, vysvetlím aké typy push správ posiela server. 

Push správy (Push message)

Google predstavil dva typy správ a to Notification message a Data message. Každá z nich má určité výhody, ale aj nevýhody. Skúsim ich naznačit, ale bližšie informácie sa nájdu na tomto mieste: About FCM Messages. 

Notification message:

• je ľahšia verzia správy s veľkosťou do 2 KB
• má preddefinované kľúče, ktoré sa nedajú meniť ani dopĺňať(vysvetlím nižšie)

Takto vydapá Notification message, všetko čo object notification obsahuje, je preddefinované a nedajú sa dopĺňať dodatočné informácie. To znamená, že ak máme ešte potrebujeme poslať iné štruktúrované (xml, json alebo iné) údaje môžeme to poslať jedine v kľúči body, ale to by bolo neprehľadné. Ostatné kľúče sú vopred preddefinované a slúžia svojmu účelu. Tak napr. kľúč title je titulok notifikácie, ktorá sa zobrazí v zariadení a body je zase text notifikácie. Kľúč icon slúži na názov ikony, ktorú je potrebné použiť, ale s tou nemám také skúsenosti a neviem si to presne predstaviť ako to má fungovať.

{
 "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
 "notification" : {
     "body" : "great match!",
     "title" : "Portugal vs. Denmark",
     "icon" : "myicon"
     }
}

Nakoniec tu máme Date message:

• správa môže byť veľkosťou do 4 KB
• môže mať užívateľom definované kľuče a hodnoty

{
 "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
 "data" : {
     "Nick" : "Mario",
     "body" : "great match!",
     "Room" : "PortugalVSDenmark"
 },
}

Nič nam nebráni v tom použiť ešte ďaľšie kľúče v Data message. Pre jednoduchší život radšej používajte Data message. Dôvod je hlavne taký, že aplikácia handluje prijatú správu, viac informácií je možné nájsť v následujúcom linku Receive Messages in an Android App. Na ozrejmenie nám poslúži následujúca tabuľka:

Tabl 1. Správanie aplikácie pri Notification a Data message

Stav aplikácie	Notification	Data	Obidve
Foreground	onMessageReceived	onMessageReceived	onMessageReceived
Background	System tray	onMessageReceived	Notification: System tray Data: v extras Intentu

Ešte raz opakujem pre lepší život je vhodnejšie na začiatku používať Data message. Takže keď pošleme Notification message a aplikácia je v popredí(foreground), tak správa sa spracuje v udalosti onMessageReceived služby MessagingService. Ak je aplikácia v pozadí (background), tak správa sa nespracuje v onMessageReceived, ale zobrazí sa v systemových notifikáciach a po tapnutý na notifikáciu otvorí hlavnú obrazovku aplikácie. Užívateľ nemá dosah pomocou aplikácie na to ako sa zobrazí notifikácia v systémovom tray bare a ani nemá dosah na to keď sa tapne aby sa zobrazila určitá obrazovka aplikácie. Ak sa jedná o Data message, život máme jednoduchší. Všetko sa môže spracovať v onMessageReceived.

onMessageReceived

Tak prišiel čas na to implementovať túto udalosť a zobraziť jednoduchú notifikáciu v system tray bare. V podstate je tento event jednoduchý, stačí dobre ohandlovať, viď. nižšie:

@Override
public void onMessageReceived(RemoteMessage remoteMessage) {
  super.onMessageReceived(remoteMessage);
  if (remoteMessage.getData().size() > 0){
      Log.d("BAGA", remoteMessage.getData().get("Nick"));
      Log.d("BAGA", remoteMessage.getData().get("body"));
      Log.d("BAGA", remoteMessage.getData().get("Room"));
  }
}

Tento event je veľmi jednoduchý. Môžeme vybuildovať notifikáciu a pending intentom, ktorý spustí nami zvolenú aktivitu alebo inú akciu, záleží podľa use case-u.

Na záver ukážem ako môžeme posielať push správy so servera do zariadenia. Príklad bude ale pod windowsom v PowerShell konzole, keďže som dlhoročný užívateľ windows.

Server a posielanie push správ

Posielať push správy budeme posielať na Google servere a ten ich bude rozposielať jednotlivým zariadeniam. Adresa, na ktorú sa majú posielať jednotlivé push správy je: https://fcm.googleapis.com/fcm/send. Posiela sa to ako HTTP POST. Treba definovať http hlavičku, kde idú polia:

• kľúč: Content-Type, hodota:  application/json
• kľúč: Authorization, hodnota: key=<moj-server-kluc>

Server kľúč je možné nájsť vo firebase konzole, nastaveniach projektu. Následne treba vygenerovať JSON, ktoré pôjde do HTTP tela. JSON bude mať následujúcu podobu:

 {
    "to":"cqlFlvpZvTw......",
        "data": {
              "Nick" : "Mario",
              "body" : "great match!",
              "Room" : "PortugalVSDenmark"
     }
}

V tomto prípade treba brať do úvahy, že kľúč "to" obsahuje hodnotu, čo je token, ktorý vygenerovalo zariadenia. Tento token vieme získať so zariadenia a ho na server. V našom prípade ho ale vytiahneme z logcat-u. Ako štruktúrovať JSON správu a aké kľúče je možné použiť je možné vidieť v následujúcom linku Firebase Cloud Messaging HTTP Protocol.

Záver

FCM je v podstate asi jednoduchšie oproti GCM. Jednotlivé rozdieli medzi FCM a GCM a ako migrovať si môžete prečítať tu: Migrate a GCM Client App for Android to Firebase Cloud Messaging. Pre vývojárov je FCM veľmi jedoduchý implementovať v aplikácií. Osobne som sa s touto technológiou stretol prvýkrát a musím povedať, že som rýchlo pochopil koncept a aj implementoval v aplikácií pre zákazníka.

Android developer options

V oblasti Android developu sa pohybujem už nejaký čas. Mnohokrát som sa čudoval, aké rôzne možnosti pre vývojara ponúka Developer options, Mnohé možnosti sú úzko špecializované a ani ja nepoužívam všetky. V tomto článku si dám za úlohu vysvetliť tieto nastavenia. Niektoré nastavenia sú špecifické pre jednotlivé verzie a s každou novou verziou môže pribudnúť nové nastavenie alebo sa odstrániť staré nepotrebné.

Povolenie vývojarských nastavení

Ako prvé je nutné povoliť nastavenia, začínajúci developeri budú mať možno na začiatku problém, keďže nastavenia sú defaultne skryté v menu. Skúsenejší už vedia, čo treba spraviť. Aby sme si vedeli ich zobraziť, treba postupovať nasledujúco:
1) otvoriť nastavenia telefónu (Settings)
2) ísť do sekcie "Informácie o telefónne" (About device)
3) rýchlo treba tapnúť na položku "Číslo zostavy" (Build number)

Po týchto krokoch by sa malo zobraziť krátke upozornenie, že ste sa stali developerom na mobilnom zariadení. Stačí vyjsť zo sekcie o úroveň vyššie a už bude možné nájsť Možnosti pre vývojárov (Developer Options).

Developer Options

Vytvoriť hlásenie o chybách (Make bug report / Take bug report) - zozbiera všetky log súbory v zariadení, pekne ich zabalí a pripraví na odoslanie. Odoslať si to môžeme buď na email, do cloudového uložiska, alebo inde. Chvíľu potrvá, než sa zozbierajú všetky údaje v zariadení a pripravia, trvá to od cca. 1 minúty do 2 minút. Keď Android zariadenie pripraví report, upozorní nás cez notifikáciu.

Výber runtime prostredia (Select runtime) - v tomto prípade máme možnosť výberu behového prostredia pre aplikácie. Buď to bude dalvik virtual machine, čo je najpoužívanejšie, alebo to bude android runtime (ART). Táto voľba je zatiaľ experimentálna a je dostupná hlavne na android verziách 4.4. Vo vyšších verziách bola znova odstránená. Google uviedlo že ART by malo byť náhradou za Dalvik prostredie.

Heslo záloh v počítači (Desktop backup password) - pomocu ADB je možné zálohovať a obnovovať súbory ako aplikácie, dáta súvisiace s aplikáciou do počítača a z počítača. Touto možnosťou je možné ochrániť zálohy heslom. Bez hesla nebude možné obnoviť zálohy

Nevypínať obrazovku (Stay awake) - táto možnosť zapríčiní to, že mobil nebude vypínať obrazovku počas nabíjania (či už cez USB port na počítači alebo elektrickú zásuvku je jedno, proste bude zapnutá). Toto je skvelé pre vývojara, ale zlé pre užívateľa na vypálenie si obrazu na obrazovku

Povoliť sledovanie Bluetooth HCI (Enable Bluetooth HCI snoop log) - pre potreby analýzy je občas nutné zachytávať bluetooth HCI(host controller interface) pakety. Povolením tejto možnosti tieto pakety uloží do súboru (/sdcard/btsnoop_hci.log). Takýto súbor je možné neskôr analyzovať pomocou programu ako je wireshark.

Chrániť kartu SD (Protect SD card) - povolením tejto možnosti vynutíme ochranu, že aplikácie nebudú môcť čítať externe úložisko pokiaľ nebudú mať permission READ_EXTERNAL_STORAGE v manifeste. Táto voľba platí pre staršie zariadenia ako Android 4.3 až Android 4.1. Tie aplikácie, ktoré proste nemajú túto permission proste havarujú na výnimke SecurityException.

Štatistiky procesov (Process Stats) - cez túto položku sa dotaneme k ďaľšej sekcii developer options, konkrétne štatistiky procesov bežiacích v zariadení. Po tapnutí na určitý proces sa zobrazí obrazovka, kde vidieť podrobné štatistiky súvisiace s procesom. Je možné sledovať ako užívateľské procesy tak aj systémove.

Ladenie USB (USB debugging) - toto treba mať zapnuté počas vývoja. Umožňuje komunikáciu medzi zariadením a počítačom cez USB port. Toto je najdôležitejšia položka pre vývojára. Okrem komunikácie je aj možné posielať ADB príkazy do zariadenia.

Odvolanie autorizácií na ladenie USB (Revoke USB debugging authorizations) -  po prvý krát, keď pripojíme zariadenie k počítaču a je povolené USB ladenie, tak si vypýta najprv, aby sme autorizovali počítač na obrazovke zariadenia (povolili počítač v zariadení). Autorizovaním počítača si v zariadení vytvorí kľúčový pár alebo otlačok počítača a budeme môcť používať USB ladenie. Ak chceme znova aby sa počítače autorizovali v zariadení, tak ako prvý krát, treba  použiť túto možnosť.

Skratka hlásenia o chybe (Include bug reports in power menu / Bug report shortcut) -  vloží možnosť zozbieraťhlásenie o chybách a odoslať ich už v cez ponuku vypnutia zariadenia (teda cez tlačítko power buttonu)

Povoliť simulované polohy (Allow moc locations) - pomocou tohto je možné manuálne nastaviť lokalizačné informácie. Na nastavenie falošnej lokalizácie je potrebné aplikáciu. Ale pred použitím aplikácie je nutné túto položku povoliť.

Vybrať aplikáciu na ladenie (Select app to be debugged / Select debug app) - máme možnosť zvoliť aplikáciu na ladenie a má to dva efekty, a to zabraňuje to vo vyvolaní chyby, ak sa zdržíte dlho v breakpointe počas ladenia a povolí ďalšiu ponuku Čakať na ladiaci nástroj.

Čakať na ladiaci nástroj (Wait for debugger) - Táto položka je zablokovaná do doby, než si zvolíte aplikáciu na ladenie pomocou hore uvedeného nastavenia. Pozdružuje štart zvolenej aplikácie do vtedy, než sa k nej pripojí ladiaci nástroj (debugger).

Overovať aplikácie z USB (Verify app over USB / Verify apps via USB) - umožňuje overovať aplikácie inštalované cez USB pomocu Google serverov. To znamená, že sa overuje všetok kód, ktorý sa posiela cez USB. Android posiela všetko na Google servere a overuje sa, či aplikácia neobsahuje nejaký známy malware.

Certifikácia bezdrôtového displeja (Wireless display certification / Authorize wireless display devices) - táto položka je dobrá pre tých, čo vlastnia televízor s technológiou Miracast-ready. V takom prípade si môžu premietať obsah displeja zariadenia na televíziu. Povolenie takéhoto premietanie je nutné povoliť túto možnosť.

Povoliť prihlasovanie WLAN Verbose (Enable Wi-Fi Verbose Logging) - táto možnosť povolí zobraziť informácie o wi-fi sieti vo wifi screen pickery a dovolí vytvoriť wpa_supplicant log, kde bude ukladať informácie o wifi.

Agresivne odovzdávať WLAN na mobilnú sieť (Aggressive Wi-Fi to Cellular handover) - ak je Wi-Fi signál slabý, tak táto možnosť dovolí rýchlo prepnúť na mobilné dáta.


Vždy povoliť funkciu WLAN Roam Scans (Always allow Wi-Fi Roam Scans) - umožňuje migrovať na silnejšiu Wi-Fi sieť, ak sa nachádza v dosahu. To znamená, že ak som pripojený na Wi-Fi so slabším signálom a v dosahu sa nachádza sieť so silnejším dosahom, Android zariadenie by malo vedieť sa prepnúť na túto silnejšiu sieť.

Veľkosť vyrovnávacej pamäte denníka (Logger buffer sizes) - dovoluje zmeniť veľkosť bufferu pre logy. Možné veľkosti sú 64K, 256K, 1M, 4M a 16M.

Zobrazovať dotyky (Show touches) - zobrazí vizualizáciu, keď zariadenie zaregistruje dotyk na obrazovke v bode dotyku.

Umiestnenie ukazovateľa (Pointer location) - táto možnosť umiestní na vrchnú časť obrazovky lištu, kde bude zobrazovať súradnice dotyku a zanechá čiaru na mieste, ako išiel dotyk po obrazovke. Jednotlivé údaje, sú následujúce: P - počet dotykov, čo zariadenie dokázalo zaregistrovať, a maximálny počet z predošlého dotyku, dX alebo X, dY alebo Y - sú súradnice dotyku v osi X a Y a rozdiel dX a dY od začatia dotyku a jeho ukončenia, ak je viacej  dotykov, ukazuje súradnice len prvého, Xv a Yv - sú zase rýchlostné vektory, ktoré zobrazujú len rozdiel v smere X a Y, Prs - zobrazujú tlak vyvíjaní na displej, je to len orientačná hodnota, keďže kapacitné displeje nedokážu snímať tlak a nakoniec je tu Size - veľkosť bodu dotyku.

Zobrazovať obnovenia obsahu (Show surface updates) - pri zmene obsahu obrazovky obrazovka preblikne. Neodporúčam pre epileptikov.

Zobraziť ohraničenia (Show layout bounds) - zobrazí ohraničenia všetkých prvkov na obrazovke.

Rozloženie sprava doľava (Force RTL Layout direction) - vypnú orientáciu obrazovky z prava do ľava.

Mierka animácie okna (Window animation scale) - umožňuje zmeniť rýchlosť animácií okien. Čím nižšie číslo, tým rýchlejšia animácia.

Mierka animácie premeny (Transition animation scale) - ako v predchádzajúcom mení rýchlosť animácie.

Mierka dĺžky animácie (Animator duration scale) - mení samotnú rýchloť zvyšných animácií.

Simulovať sekundárne displeje (Simulate secondary displays) - umožňuje simulovať iné rozlíšenia obrazoviek. Osobne mi to, ale nefungovalo najlepšie.

Vykreslovať pomocou GPU (Force GPU rendering) - núti vykreslovať 2D grafiku pomocou GPU v aplikáciach.

Zobraziť obnovenia s GPU (Show GPU view updates) - všetky view-y, ktoré vykresľuje GPU, budú mať červený rámček okolo seba po zmene obsahu.

Zobraziť akutalizácie HW vrstiev (Show hardware layers updates) - prebliknu prvky na zeleno, keď budú hardwerovo aktualizované.

Ladenie prekresľovanie GPU (Debug GPU overdraw) - zobrazí pomocou farieb to, ako často sa musia prvky na obrazovke prekresľovať. Použité sú tieto farby: modrá - ak sa iba raz prekreslí prvok, zelená - ak sa prekreslí dvakrát prvok, ružová - ak sa prvok prekreslí trikrát a červená ak sa prvok prekreslí štyrikrát a viac krát. (Viac info viď. Debug GPU Overdraw Walkthrough. )

Ladenie operácií neobdĺžnikových klipov (Debug non- rectangular clip operations) -

Vynútiť 4x MSAA (Force 4x MSAA) - vynúti multi vzorkovú anti-aliasing technológiu. Krajšie vykresľovanie, ale na úkor výkonu.

Zakázať hardvérové prekrytia (Disable HW overlays) - skracuje čas spracovania aplikácií, ktoré niečo zobrazujú na displeji. Bez toho aplikácia používa zdieľanú video pamäť a musí stále kontrolovať kolízie.

Simulácia farebného priestoru (Simulate color space) - pomáha vývojárom vidieť, ako vyzerá aplikácia pre farboslepých užívateľov.

Použiť AwesomePlayer (zastarené)(Use AwesomePlayer (deprecated)) - rozdiel medzi NuPlayerom a AwesomePlayerom je hlavne v načítaní online videa. NuPlayer načítava online videa rýchlejšie. Keďže vo verzii Android 5 je toto nová verzia a nie je ešte vyladená, tak sa dá prepnúť na staršiu verziu, ale touto možnosťou. V neskorších verziách môže táto voľba úplne zmiznúť.

Vypnutie smerovania zvuku do USB (Disable USB audio routing) - nebude posielať audio výstup na USB port, ak je pripojené audio zariadenie v USB porte.

Prísny režim bol povolený (Strict mode enabled) - pri povolenej možnosti bude obrazovka blikať, ak aplikácia bude vykonávať dlhotrvajúcu operáciu na hlavnom vlákne

Zobraziť využitie CPU (Show CPU usage) - v pravom hornom rohu obrazovky bude zobrazovať informácie o využití CPU

Profil vykreslovania GPU (Profile GPU rendering) - spraví grafickú vizualízáciu vykresľovania GPU v ľavom dolnom rohu, alebo môžeme zapísať do súboru

Trasovanie OpenGL (Enable OpenGL traces) - povolí sledovanie OpenGL chýb a zapíše ich do log súboru

Neuchovávať aktivity (Don't keep activities) - ukončí všetky aktivity po odídení z hlavného view. Predlžuje výdrž batérie, ale zato dlhšie sa zapína aplikácia.

Limit procesov na pozadí (Background process limit) - môžeme ovplyvniť počet súčasne bežiacich procesov na pozadí.

Zobrazovať všetky ANR (Show all ANRs) - zobrazí dialóg Aplikácia neraguje pre všetky aplikácie a aj tie, ktoré bežia na pozadí.


Snažil som sa zhrnúť všetky možnosti, ktoré sa nachádzali v Developer options naprieč viacerými verziami Androidu. Nedostal som sa akurát k verzii Android 6 a 7, keďže ešte nevlastním žiadne zariadenie, ale to sa zmení čoskoro. Ak je niečo, čo som nespomenul k nastaveniu alebo vynechal nejaké nastavenie, budem rád za pripomienky. Jednotlivé nastavenia sú v samotnej obrazovke oddelené cez hlavičku ešte do kategórií ako Debugging, Input, Drawing, Hardware-accelerated rendering, Monitoring, Apps. Doplním, že systém Android je tak populárny, že ho viacerí výrobcovia HW používajú vo svojich produktoch v rôznych variantách, spomeniem Amazon a ich systém Fire OS. Ten má veľa spoločného s Android a aj Developer Options nastavenia. Takže čo platí pre Android, platí aj pre Fire OS. Pri písaní článku som vychádzal z dokumentácie, osobných skúseností a z týchto článkov:

All about your phone's developer options

Android Developer Options: enable, disable and use Read more

V ďalšom článku pridám Developer Options pre Android Wear Motorola Moto 360.

Android - Product Flavors

Od nástupu Android Studia bol predstavený aj nový buildovací systém Gradle. Tento systém je open source, flexibilný, postavený na groovy jazyku, v mnohom uľahčuje prácu vývojárovi. 

Ako android vývojár som sa stretol s tým, že aplikácia mala byť publikovaná na dva odlišné obchody s použitím mierne odlišných funkcií špecifických pre daný obchod. Typické funkcie špecifické pre dané obchody bývajú nákupy v aplikácii alebo prostredníctvom reklamy. Tých obchodov, kde môžeme publikovať aplikácie je viacero, spomeniem ich zopár: 

• Google play - najznámejší, keďže sa jedná o Android systém. 
• Amazon App Store - Amazon vytvoril vlastnú variantu Android Systému pod názvom Fire OS. 
• Samsung Galaxy Apps - obchod od Samsungu, čo viac k tomu dodať. 

S publikovaným aplikácie na dva alebo viacej obchodov nie je problém. Problém nastáva pri tom, keby sme chceli použiť v aplikácii špecifické funkcie pre daný store ako nákupy v aplikácií. Napr. Amazon nepodporuje Google Play Services v ich systéme Fire OS (podporuje In-app Purchases), čo znamená, že nevieme robiť nákupy v Google obchode (ten má zase In-app Billing). Tento problém sa dá riešiť viacerými spôsobmi. Jeden spôsob je ten, že budem mať dva odlišné projekty v Android Studiu jednej aplikácie, väčšinu kódu budú mať oba projekty identickú, budú sa odlišovať len v implementáciach nákupov. Ak nájdem chybu v kóde, ktorý je rovnaký pre oba projekty, tak to znamená aj dve rovnaké opravy kódu v dvoch projektoch. Tiež prepínanie sa medzi projektami počas vývoja nie je najrýchlejšie.

Druhý spôsob bude taký, že budem mať jeden projekt a nakonfigurujem v buildovacom systéme gradle product flavors. Tento spôsob je elegantnejší, jeden kód, ktorý je rovnaký(zdielaný) pre obe verzie aplikácie, bude len raz a pridáme implementácie funkcií pre konkrétne obchody oddelene od zdieľaného kódu. Bližšie o build flavors sa dá dočítať na vývojarských stránkach Android: Product Flavors and Variants. Vysvetlím použitie druhého spôsobu na príklade. Majme projekt, ktorý má následujúcu štruktúru, viď. následujúci obrázok:

Android Studio - štruktúra projektu

Začneme tým že pridáme niekoľko riadkov do súboru build.gradle, ktorý sa nachádza v aplikačnom module (app).

productFlavors{
         google{
            versionCode 1
            versionName '1.1'
         }
          amazon{
            versionCode 2
            versionName '1.2'
          }
}

Po vložení hore uvedených riadkov a zosynchronizovaní build.gradle nám vytvorí niekoľko variant a to amazonDebug, amazonRelease, googleDebug, googleRelease, ako vidieť na obrázku nižšie.

Android Studio - Build Variants

Pred synchronizáciuo sme mali len dve build varianty a to Debug a Release. Keby sme pridali ďalšiu product flavors, tak Android Studio nám vytvorí 6 build varianta, ktorá bude mať vypadať následujúco:

<meno>Debug 

<meno>Release

V Android Studiu sa vieme teraz prepínať medzi build variantami. Momentálne máme len build varianty vytvorené, keď chceme ešte doplniť kódy špecifické pre každú variantu potrebujeme vytvoriť adresárovú štrukúru zdrojových kódov v Android Studiu. Štruktúra adresárov teraz bude vypadať následujúco:

Android Studio - Štruktúra projektov po pridaní product flavors

Túto štruktúro nám Android Studiu nevytvorí, tú si musíme vytvoriť sami. Štruktúra pre zdrojové kódy je podľa následujúceho vzorca:

src\<productFlavors-name>\java\<package>\SpecifickaImplementaciaPodlaFlavoru.java

Pre Resources je štruktúra jednoduchšia:

src\res\layout\LayoutSpecifickyPreProductFlavor.xml

V Adresáry src\main sú umiestnené všetky zdrojové kódy, ktoré nie sú špecifické pre určitú product flavor. Ako príkladom ukážem aplikáciu, ktorá bude robiť dve veci, záleži od jej product flavor. Amazon flavor bude robiť rozdiel dvoch čísel, bude mať aj rozdielne pozadie activity oproti google flavor. Zatiaľ čo google flavor bude dve čísla spočítavať. V adresári src\main je trieda Calculating.java, ktorá je spoločná pre obe flavors, jej zdrojovy kód je následujúci:

package test.vuforia.goodrequest.com.gradletest;

public class Calculating {

     public static int Add(int number1, int number2) {
         return number1 + number2;
     }

     public static int Substraction(int number1, int number2) {
         return number1 - number2;
     }
}

Layout pre google flavor je následujúci:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:id="@+id/activity_main"
android:layout_width="match_parent"
android:layout_height="match_parent" 

android:orientation="vertical" 

android:background="@color/black">

<TextView android:layout_width="wrap_content" 

android:layout_height="wrap_content" 

android:text="Cislo 1" 

android:textColor="@color/white"/> 

<EditText android:id="@+id/number1"

 android:layout_width="match_parent"

 android:layout_height="wrap_content" 

 android:background="@color/white" 

 android:inputType="number"/>

<TextView android:layout_width="wrap_content"

 android:layout_height="wrap_content"

 android:textColor="@color/white" 

 android:text="Cislo 2"/>

 <EditText android:id="@+id/number2" 

 android:layout_width="match_parent" 

 android:layout_height="wrap_content"

 android:background="@color/white"

 android:inputType="number"/>

 <Button android:id="@+id/sucet"

 android:layout_height="wrap_content"

 android:layout_width="wrap_content" 

 android:text="Sucet" /> 

<TextView android:id="@+id/vysledok"

 android:layout_width="wrap_content"

 android:layout_height="wrap_content"

 android:textColor="@color/white"

 android:textStyle="bold"/>

</LinearLayout>

Layout pre Amazon flavor je rovnaká, rozdiel je len v použitých farbách pozadia LinearLayoutu a Button má iný textový popisok a id. Pod popiskom myslím android:text attribut. Trieda MainActivity.java má následujúci kód:

package test.vuforia.goodrequest.com.gradletest;

import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;

public class MainActivity extends AppCompatActivity {

private Button sucet;
private EditText cislo1, cislo2;
private TextView vysledok;

@Override
protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);
      cislo1 = (EditText) findViewById(R.id.number1);
      cislo2 = (EditText) findViewById(R.id.number2);
      vysledok = (TextView) findViewById(R.id.vysledok);
      sucet = (Button) findViewById(R.id.sucet);
      sucet.setOnClickListener(new View.OnClickListener() {
          @Override
          public void onClick(View v) {
               if ((cislo1.getText().length() != 0) && (cislo2.getText().length() != 0)) {
                     int scitanec1 = Integer.valueOf(cislo1.getText().toString());
                     int scitanec2 = Integer.valueOf(cislo2.getText().toString());
                     vysledok.setText("" + Calculating.Add(scitanec1, scitanec2));
                }
           }
      });
}
}

V podstate aj amazon flavor je velmi podobný, odlišuje sa len v implementácii OnClick listeneru buttonu: 

rozdiel.setOnClickListener(new View.OnClickListener() {
     @Override 

      public void onClick(View v) {
            if ((cislo1.getText().length() != 0) && (cislo2.getText().length() !=0)){
                  int mensenec = Integer.valueOf(cislo1.getText().toString());
                  int mensitel = Integer.valueOf(cislo2.getText().toString());
                  vysledok.setText("" + Calculating.Substraction(mensenec,mensitel));
           }
     }
});

Takýmto flexibilným spôsobom vieme vytvoriť viacero verzií jednej aplikácie rozlišujúcej sa vo vzhľade alebo vo funkcii. Nepotrebujeme k tomu žiadne dva projekty, stačí nám jeden. Pre úplnosť uvádzam výpis build.gradle súboru nachádzajúceho sa v app module: 

apply plugin: 'com.android.application'

android {

    compileSdkVersion 24

    buildToolsVersion "24.0.2"

    defaultConfig {

        applicationId "test.vuforia.goodrequest.com.gradletest"

        minSdkVersion 18

        targetSdkVersion 24

        versionCode 1

        versionName "1.0"

        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"

    }

    buildTypes {

        release {

            minifyEnabled false

            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

        }

    }

    productFlavors{

        google{

            versionCode 1

            versionName '1.1'

        }

        amazon{

            versionCode 2

            versionName '1.2'

        }

    }

}

dependencies {

    compile fileTree(dir: 'libs', include: ['*.jar'])

    compile 'com.android.support:appcompat-v7:24.2.1'

}

Text je publikovaný aj na blogu som písal aj pre spoločnosť GoodRequest s.r.o., kde som v dobe písania pôsobil.

Android CrackeMe

Toto bude netradičný článok. Osobne sa pohybujem v android vývoji už určitý čas a začal som sa zaujímať o to, ako funguje ochrana aplikácií na tejto platforme. Pár aplikácii som si pre zvedavosť crackol, ale nepoužívam ich a ani nedistribuujem ďalej. Vysvetľovať to, ako som postupoval na takejto aplikácií nie je dobré a ani férové voči vývojárovi, je to nelegálne. Preto som si vybral na to špecialne určenú aplikáciu CrackMe, ktorá bolá napísaná vývojárom ako challenge pre tých, čo sa radi vŕtajú v aplikáciách a zisťujú ako fungujú, teda ovládajú taje umenia reverzného umenia.

Na naše účely poslúži aplikácia od Deurus užívateľa, ktorý napísal viacej druhov crackme pre rôzne platformy, link Dereus. Užívateľ ako požaduje vo výzve vytvorenie generátora sériových čísel alebo patchovanie aplikácie. Prikladám odkaz na súbor, na ktorom vysvetlím postup, treba sa registrovať a stiahnúť: CrackMe04. Toto opisujem ako moje zmýšľanie pri riešení tohto crackme.

Ako nástroje som použil:

1. notepad++  so svýraznovačom syntaxe (link na zvýraznovač syntax highlight)
2. apktool, ktorý slúži na reverzne inžinierstvo súborov apk, link Apktool 
3. decompilér JEB, použil som demo verziu.

Ako prvé som nahral aplikáciu do mobilu (pri malware radšej do virtuálneho stroja AVD). Pozrel som ako vyzerá, zistil som, že má tri obrazovky (Activity). Samotné apk som prešiel cez apktool:

java -jar apktool d AndroidCrackme.apk -o CrackMe

 Pozrel som si verziu a VersionName aplikácie (netradičné hodnoty). Pozrel som si certifikát:

keytool.exe -printcert -jarfile AndroidCrackme04.apk

Obr.1 Certifikát aplikácie

Otvoril som manifest a pozrel som štruktúru aplikácie. Jeden vstupný bod do aplikácie je súbor Splash a niekoľko povolení ako čítanie pamäťovej karty, stav WIFI, Bluetooth.

Obr.2 Manifest.xml aplikácie

Pozrel som na štruktúru adresárov a súborov. V zdrojových súboroch som v adresári Raw našiel zvukové súbory. Pozrel som ešte layouty ako vyzerajú. Z názvov súborov je jasné, že je použitá obfukácia kódu.  Dal som si vypísať reťazce vo všetkých smali súboroch:

findstr /i /n "const-string" *.smali

Z výpisu som nemohol nič užitočné vyčítať. Otvoril som si teda súbor Splash.smali v notepad++.  Keďže je to aktvita (Activity), tak vstupným bodom do nej je metóda onCreate, ale hľadal som aj onResume a onStart (tie sa ale v tomto súbore nenachádzajú). V metóde onCreate vloží do premenných b="classes.dex" (súbor nachádzajúci sa v AndroidCrackme04.apk, teda dalvik kód celej aplikácie) , c="cr4.dat", d="MD5" (pre použitie hashovania). Potom zavolá metódu a()V, kde kontroluje to, či aplikácia bola upravená. Tam som našiel túto podmienku, ktorú stačí iba zmeniť na opačnú (viď. zakomentovaný kód a pod ním nekomentovaný kód).

Obr.3 Nájdena ochrana

Ok, to je ochrana aplikácie proti zmene v kóde(patchovaniu). Aktivita Splash nakoniec spustí nový Handle, ktorá bude aktivita CrackMe a seba ukončí. V CrackMe aktivite je znova vstupom, len onCreate metóda. Pozrel som aj ostatné metódy, čo robia ako a(Landroid/content/Context;)Ljava/lang/String;  vráti VersionName

b(Landroid/content/Context;)I vráti Verziu aplikácie. Znova metóda  d()V, kde je ochrana proti patchovaniu aplikácie, na konci som upravil podmienku tak, aby prešla opatchovaná aplikácia. Metóda a()Ljava/lang/String;  číta CID karty, teda jej ID. Ostatne metódy robili úpravy s údajmi, ktoré dostali ako napr. odstránenie znaku ":" z MAC adresy a pod..

Zameral som sa teda na Metódu onCreate, kde je nakoniec algoritmus na overovanie Mena, Serial kľúča. Neštudoval som ho do detailov. V metóde ale vidím, že aplikácia získava MAC adresu wifi karty, adresu bluetooth karty, ale aj ID SD karty, ktoré spacuváva. Našiel som ale toto viď. obrázok obr.4, porovanie sériového čísla, tak som zmenil podmienku, čo bola kontrola zadaného sériového čísla.

Obr.4 Druhá časť overenia

Nakoniec som uložil zmeny, zabalil aplikáciu znova pomocou apktool:

java -jar apktool.jar b Eset -o AndroidCrackme_TEST.apk

Ešte som podpísal aplikáciu:

jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore [moj keystroke]

[AndroidCrackme_TEST.apk] alias_nam

Ohľadom nástroja JEB, nemám licenciu a mohol som použiť len demo, takže niektoré metódy neboli dekompilované, tak som kontroloval a porovnával smali kód s JEB aplikáciu. Ak toto používate, tak máte ľahšiu analýzu,  čo je veľmi dobré, a teda je jednoduchšie robiť analýzu v jave.

Vyjadrenie na záver, aplikácia obsahuje aj prehrávač hudby AndModPlug od Peculiar Games, do projektu sa dostane v podobe knižnice. Autor tohto cracku vytvoril viacej druhov cracku, ako pre desktopy, tak pre android.

Keď niečo nefunguje v SharePointe - Get-SPLogEvent

Utilita Get-SPLogEvent je užitočná pre SharePoint Administrátorov, ale aj programátorov. Štandardne je zabudovaná v SharePoint-e ako súčasť SharePoint snappin. Slúži na zobrazovanie a vyhľadávanie v diagnostických logoch, čo vytvorí SharePoint. Na jej použitie ju treba zaviesť do PowerShell sessiony ako snappin. Dá sa to dvoma spôsobmi, a to automaticky, keď spustíme z Ponuky Štart>All Programs>Microsoft SharePoint 2013 Products>SharePoint 2013 Management Shell, čo je najjednoduchšia varianta viď. obr.1.

Obr.1 Ponuka Štart pre výber SharePoint 2013 Management Shell

Alebo snappin zavedieme manuálne, ale najprv musíme vedieť, ako máme zaregistrovaný snappin v systéme, na to pomôže riadok v PoweSshell-y, jeho výpis vidieť na obr.2:

get-pssnapping -registered

Obr. 2 get-pssnappin

Po obhliadnutí zaregistrovaných snappinov vidieť, že máme SharePoint snappin pod menom Microsoft.SharePoint.PowerShell  v systéme ho môžme zaviesť do sessionu pomocou cmdletu:

add-spsnappin -name Microsoft.SharePoint.PowerShell

Keďže používam na serveri PowerShell v spojení so SharePoint-om, tak som si pridal do profilu PowerShell-u predchádzajúci cmdlet, aby sa mi zaviedol SharePoint snappin vždy po otvorení PowerShell-u. Po zavedení snappinu môžme používať všetky cmdlety určené pre SharePoint. Nás ale zaujíma Get-SPLogEvent. Samotný cmdlet bez parametrov zobrazí všetky logy. Ok, ale výhoda utility nespočíva v tom, že môžme si zobraziť všetky logy, ale v tom, že môžme filtrovať na základe určitých parametrov v logoch.  Pozrime sa na nápovedu od cmdletu, obr.3.

get-help get-splogevent

alebo skrátená verzia

help get-splogevent

Obr.3 Nápoveda alebo manuálová stránka pre get-splogevent

Vidieť je niekoľko užitočných parametrov ako Directory, EndTime, StartTime, MinimumLevel. Príklady použitia si môžme pozrieť aj v nápovede, aby sme videli len priklady stačí uviesť cmdlet:

help get-splogevent -examples

Výstup príkazu je vidieť na obr.4.

Obr.4 Príklady použitia get-splogevent

Ok, to sú už menšie možnosti filtrovania, ale stále to nie je všetko a ani postačujúce. Čo tak filtrácia na základe Correlation, Category alebo Area, resp. iných v logu obsiahnutých informácií. Tým, že je PowerShell objektovo orientované skriptovacie prostredie, tak máme širšie možnosti práce s údajmi z príslušných cmdlet-ov. Pozrime na členov get-splogevent cez príkaz, viď. obr.5:

get-splogevent | get-members

Obr.5 Členovia cmdlet-u Get-SPLogEvent

Na základe určitého Correlation vieme získať potrebný výstup:

get-splogevent | where-object {$_.Correlation -eq '79012b9d-692f-f014-a228-52715da5e838'}

alebo získať všetky chyby úrovne Critical:

get-splogevent | where {$_.Level -eq 'Critical'}

Čo tak zobraziť ako výstup iba potrebné informácie ako message, category všetkých chýb úrovne critical:

get-splogevent | where {$_.Level -eq 'Critical'} | select-object Message,Category

Môžme kombinovať vlastnosti a vytvárať tak zložitejšie filtre. Za pomoci ďalších cmdlet-ov ako Where-Object, Select-Object, Format-List, Format-Table a ďalších vieme pekne dolovať informácie z logov a následne si ich zobraziť v PowerShell-y. 

SharePoint obsahuje veľké množstvo cmdlet-ov a v priebehu následujúcich článkov ich bližšie predstavím. Koľko ich je a ktoré to sú, si môžme pozrieť pomocou:

get-command -module Microsoft.SharePoint.PowerShell