Android SitruunaMarenkiPiirakkaa (Lemon Meringue Pie 4.5 tai 5.0?)

Android L saanee nimekseen Lemon Meringue Pie, eli sitruunamarenkipiirakka. Luvassa on jännittävää uutta monessakin mielessä, ja ei ole ihan kaukaa haettua että versionumero voisi kutitella viitosta.Toisaalta huhut puhuvat myös versionumerosta 4.5 (sisäinen buildinumero tällä hetkellä 4.4.99 😉

Tämä on myös jälleen uuden alueen valtausta: Release ei ole suunnattu vain puhelimiin ja tabletteihin, vaan se syöksyy suoraan wearables-laitteisiin (mmmm päällepuettaviin? 😉 Ja samalla voisi olettaa paukahtavan myyntiin uunituoreen Nexus 6 laitteen ja tiedä mikä tabletti sieltä tuleekaan…  Tänmä vuonna tulee kuitenkin sekä marenkipiirakka että nexus laitteet.

Android L version ominaisuuksista olen blogannut jo aiemmin. Merkittävä uudistus on UI-heivaus Material Design, joka noudattelee myös omia mieltymyksiä yksinkertaisuuden ja selkeyden suhteen. Siihen liittyy mm. värien ja tilankäytön ohjeita, sekä ’hero element’, joka animoi itsensä näkymien välillä. Ei taida olla testiantipattern local hero enää, tämä liitelee minne haluaa. Syvyyttä, varjostuksia, helppoja animaatioita, ripple efektejä. Onhan nämä kaikki jo nähty, mutta jos tämä opettaisi Android koodaajanörttejä miettimään myös visuaalista puolta vähän enemmän, se voisi olla vaivan arvoinen. Minä itse koodaajanörttinä en tunne kuin neljä väriä, ja niistäkin kaksi on mustia – mutta Material Design näyttää omaan silmään hyvältä yksinkertaisuuden ja avaruuden vuoksi.

Mitä muuta uutta? Taas parannuksia notifikaatioihin, lukitusruutuun, ja moniajoon. Mielenkiintoisena trendinä lukitusruudusta pääsee käsiksi yhä useampaan asiaan ilman että puhelinta tarvitsee varsinaisesti avata. Android Wear ja Android Fit tuki tietysti mukana käyttiksessä – mukaanlukien proximity unlock.

Terve Android-kännykkä jota nyplätään paljon näyttää suurinpiirtein tältä: Ruutu syö suurimman osan akusta.

Terve Android-kännykkä jota nyplätään paljon näyttää suurinpiirtein tältä: Ruutu syö suurimman osan akusta.

 

Akkukesto on jälleen kerran fokuksessa. Henkilökohtaisesti itse kelpuuttaisin Nexus laitteen jossa on tuplakokoinen akku. Mutta tulossa siis virtapihimpää Android käyttistä ja Project Volta – joka opettaa koodaajia tekemään virtapihimpiä sovelluksia. Tässä yhteydessä haluan jakaa julkista piiskaa Instagramille, jota en voi Nexuksessa pitää ollenkaan päällä tausta-ajossa: Se syö akun ennätysajassa. Muutenkin Android laitteiden surkea akkukesto on hyvin suuresti huonosti tehtyjen yksittäisten sovelusten syytä. Erityisesti piiskaa sovelluksille jotka eivät osaa vapauttaa sensorirajapintoja kun eivät niitä tarvitse. Ei tässä silti juhlimaan päästä noin niinkuin käyttöjärjestelmänkään puolesta, joten jokainen parannus on tervetullut.

Dalvik vs ART

Ja tietysti 64-bittisten prosessorien tuki ja fokuksen siirtyminen Dalvikista ART kirjastoon – jonka pitäisi olla n. kaksinkertainen nopeudeltaan. Hupaisana piirteenä nopeus on saatu kääntämällä aikanaan Javassa keksitty optimointi päälaelleen. Just-In-Time saa kyytiä ja sensijaan optimoidaan nyt Install-Time. Itse olen pyöritellyt ART:ia jo Nexus vitosessa pitkät ajat, ja nopea se on, mutta joidenkin softien kanssa vähän ongelmia. Jos siitä tulisi ensisijainen ympäristö, se ei olisi haitaksi.

Google Glass - What's Best In Life?

Ai niin, ja parisataa kirjoitettua artikkelia paukkui kasaan hetki sitten. Näemmä tästä omasta pikku päiväkirjaprojektista on paisunut kohtuullinen. Statistiikan mukaan n. 30 000 näyttökertaa sivuilla kaiken kaikkiaan, ja nykyisellään 400-1000 näyttökertaa kuussa. Mitään muutahan en niistä kostu kuin tiedon että en turhaan juttuja muille täällä jaa. Kiitokset kaikille jotka ovat täällä piipahtaneet 😉

Java 9 tulee – sitten joskus

En tiedä onko muiden tutkaan osunut, mutta Java 9 versiosta on julkaistu jo ennakkotietoja – kuten asiaan kuuluu uutta versiota pukkaa parin vuoden välein, ja tässä olisi tarkoitus tuoda loput jo aikanaan Java 8:aan (ja 7:aan) suunnitelluista piirteitä. Erityisesti Jigsaw modulaarisuus olisi tarkoitus saada viimein ulos tuutista.

Mukana olisi tulossa mm. uusi, kevyt JSON API, HTTP 2 client, lisää pääsyä käyttöjärjestelmän prosesseihin, säie/lukitus suorituskykyä, fiksumpaa käännöstä, koodicachea, rajapintaa rahan käsittelyyn, ja tietysti se Jigsaw.

Tuossa olisi esimerkkiä miten tuleva Money API näyttäisi:

public class Product { 
	private String name; 
	private Money price;	
            //getter and setter 
}

public class CreateCurrencyUnit 
{ 
    public static void main( String[] args ) 
    { 
        CurrencyUnit real = MonetaryCurrencies.getCurrency("BRL"); 
        CurrencyUnit dollar = MonetaryCurrencies.getCurrency(Locale.US); 
        System.out.println(real); //BRL – the Brazilian currency
        System.out.println(dollar); //USD – the north American currency
    } 
}

Onkohan tuossa tarpeeksi? Aikanaan kun Scalalla tuli tehtyä enemmän, Javaan tuntui suorastaan pahalta palata, samoin JavaScriptiin. Toisaalta Javan rooli on olla se yritysmaailman sveitsin armeijan linkkari, ja Lingua Franca, sen roolina ei olekaan olla se uusin ja jännittävin. Nämä ovat joka tapauksessa tuloillaan 2016 joten vielä pari vuotta ehtii fokus elää, todennäköisesti modernimpia uudistuksia ei muutenkaan haluta pultata paikalleen liian aikaisin.

Tässä lähdelinkkejä:

https://weblogs.java.net/blog/otaviojava/archive/2014/08/25/java-9-coming-money-api

Tuosta löytyisi: http://java.dzone.com/articles/java-9-features-announced

Tuolla pääsee vielä mukaankin jos on intohimoa: http://openjdk.java.net/projects/jdk9/

Ja voi sen jo ladatakin: https://jdk9.java.net/download/

Glassfish remote deployment

Olen viritellyt Glassfish serveriklusterin deploymentin parissa. Ideana on saada etäkoneelta buildi, esim. Jenkins tai kehittäjäkone, tipauttamaan nätisti buildin tuotokset serverille jossa niitä voidaan testata ja demoilla.

Tähän on moniakin vaihtoehtoja:

– Glassfish serverissä on autodeploy-kansio, eli jos sinne siirtää tiedoston esim. scp:llä tai ftp:llä, se nousee itsestään pystyyn

– Deployn voi tietysti tehdä käsin, glassfish hallintanäyttöjen kautta

– Cargo plugin on maineikas sen suhteen, että se osaa asennella monellekin eri serverille kun vain kerrotaan miten

– Asadmin työkalu toimii komentoriviltä, se kykenee myös asentamaan tuotoksia

– Joku muu jonka olen unohtanut :p

Tuosta listasta kokeilen ensiksi Cargo pluginia. Se vaikutti muuten lupaavalta paitsi ei toiminut ollenkaan. Ilmeisesti pulmia teeman deploy/redeploy välillä, ja monessa lähteessä mainittu force=true ei tuntunut auttavan. Ongelma siis että jos serverillä ei ole sovellusta, pitäisi tehdä deploy, myöhemmillä kerroilla taas redeploy. En saanut tätä kuitenkaan toimimaan. Sain kivoja nullpointer exceptioneitä Glassfish nelosen kanssa.

Noista tiedostopohjaisista kujeista en ole suunnattoman innostunut, eli käytän niitä vasta jos on pakko. Tiedostojen kanssa on ongelmia mm. lukituksen/säikeiden ja transaktionaalisen eheyden kanssa siirrossa, sekä jälkien putsauksen kanssa.

Asadmin työkalua tuli käyteltyä ja virittelin sen päälle maven exec tehtävän joka osaa sitä ajaa. En ole vielä aivan tyytyväinen vakauteen, mutta toistaiseksi riittävä ratkaisu.

Asadminilla onnistuu .war paketin asennus verkon yli serverille esim. näin:

c:\glassfish4\bin\asadmin deploy --host devserver.mycompany.com --force=true --availabilityenabled=true --target cluster1 --virtualservers server c:\projects\MyProject\target\MyDeliverable.war

Tämä komento hoitaa myös redeployn. Tämä kuitenkin edellyttää että komennon ajavalla käyttäjällä on salasanatiedot jo talletettuna profiiliinsa. Saamme tästä hieman geneerisemmän näin:

c:\glassfish4\bin\asadmin --user admin --passwordfile c:\glassfish4\password --host devserver.mycompany.com deploy  --force=true --availabilityenabled=true --target cluster1 --virtualservers server  c:\projects\MyProject\target\MyDeliverable.war

Tässä koukataan salasanat salasanatiedostosta, joka on aluksi Glassfish serverin kansiossa (paikallinen asennus, jotta saamme asadmin työkalun käyttöön). Sen voi suojata haluamallaan tavalla.

Tältä näyttäisi mavenin exec plugin:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>exec-maven-plugin</artifactId>
  <version>1.3.1</version>
  <configuration>
    <executable>${glassfish.asadmin.executable}</executable>
    <arguments>
      <argument>--user</argument>
      <argument>${glassfish.user}</argument>
      <argument>--passwordfile</argument>
      <argument>${glassfish.password.file}</argument>
      <argument>--host</argument>
      <argument>${glassfish.remote.host}</argument> 
      <argument>deploy</argument> 
      <argument>--force=true</argument>
      <argument>--availabilityenabled=true</argument>
      <argument>--target</argument>
      <argument>cluster1</argument>
      <argument>--virtualservers</argument>
      <argument>server</argument>
      <argument>${project.build.directory}/${project.build.finalName}.war</argument>
    </arguments>
  </configuration>
  <executions>
    <execution>
      <goals>
        <goal>exec</goal>
      </goals>
    </execution>
  </executions>
</plugin>

 

Ja tältä näyttävät tuossa käytetyt propertyt:

<glassfish.asadmin.executable>c:/glassfish4/bin/asadmin.bat</glassfish.asadmin.executable>
 <glassfish.user>admin</glassfish.user>
 <glassfish.password.file>${basedir}/password</glassfish.password.file>
 <glassfish.remote.host>devserver.mycompany.com</glassfish.remote.host>

Ja propertythän voi taas pistää profiilien alle, samoin kuin muutenkin exec konfiguraatiot, eli näillä voi tarvittaessa joka devaaja tai joka ympäristö asennella eri serverille eri tiedoilla.

D3 Data Driven Documents, Angular ja Require

Hiljattain tuli ajankohtaiseksi tutustua taas uuteen JavaScript-herkkuun, tällä kertaa kirjasto nimeltään d3.

Kirjasto muodostaa ytimen datan visualisoinneille ja animaatiolle. Mistä itse pidän tässä, se ei ole svg kirjasto, eikä komponenttipaketti, vaan se on framework omalle visualisointityölle – joka voi ulottua datan visualisoinnista taulukkoon saman datan visualisoimiseen vaikkapa kuplakaavioksi tai lämpökartaksi. Ja kaikki kauniisti animoitavissa. Esitystapana voi olla html, tai svg, tai mitä ikinä mukavaa tulevaisuus tuokaan mukanaan. Tässä on jotain samaa kutkuttavuutta kuin Polymerissä (ja en malta odottaa että näitä kahta pääsisi sekoittelemaan vähän 😉

Tuossa muutama d3 niksi:

// Color all paragraphs randomly
 d3.selectAll("div#main>p").style("color", function() {
 return "hsl(" + Math.random() * 360 + ",100%,50%)";
 });
// Color all paragraphs alternating shades
 d3.selectAll("div#main>p").style("background-color", function(d, i) {
 return i % 2 ? "#fff" : "#eee";
 });

Miten tämä liittyy Angular+Require yhdistelmään? Alunperin d3 toimi siten että se luo sivulle globaalin muuttujan $window.d3, jonka takaa toiminnot löytyivät. Versiossa 3 siitä on kuitenkin tullut Require-tietoinen: Jos se havaitsee require-kirjaston läsnäolon, globaalimuuttujaa ei luoda. Tämä taas sai monet d3 riippuvaiskirjastot hajoamaan. Nyttemmin niitä on myös korjailtu. Siltikin, jos d3 globaalia ei löydy ja se jostain syystä tarvittaisiin, tässä on niksi siihen:

shim: {
  'd3': {
    exports: 'd3',
    init: function() {
      window.d3 = d3;
    }
   }
 }

Mutta sittemmin tosiaan monet kirjastot toimivat oikein myös requirejs ja d3 versio 3:sen kanssa. D3:sen päälle on tehty laajennuskirjastoja, kuten esim. nvd3, josta löytyy graafeja ja mittareita.

Yksi mielenkiintoinen juttu d3 + angular yhdistelmässä on: Niissä on periaatteessa päällekkäisyyttä, koska Angular sitoo model-arvoja DOM:iin, ja d3 sitoo model-arvoja DOM:iin. Tästä huolimatta näiden hybridejä on tehty usein, mutta on myös mahdollista käyttää d3:sta vain Angularin apuna, tukikirjastona, ja antaa Angular direktiivien hoitaa varsinainen renderöinti. d3 omaa hyviä svg-apukirjastoja joista on hyötyä tässäkin, esim:

 var pointerLine = d3.svg.line()
   .x(function(d) {
     return d.x;
   })
   .y(function(d) {
     return d.y;
   })
  .interpolate("basis");

Tai laajempana:

 svg.append("svg:path")
 .style("fill", color)
 .attr("d", d3.svg.arc()
   .startAngle(scope.valueToRadians(start))
   .endAngle(scope.valueToRadians(end))
   .innerRadius(0.65 * radius)
   .outerRadius(0.85 * radius))
 .attr("transform", function() {
   return "translate(" + cx + ", " + cy + ") rotate(270)";
 });

Parhaimmillaan siis d3 ja Angular voivat muodostaa käsi kädessä kauniin liiton 😉

Linkki d3-sivuille:

http://d3js.org/

Linkkivinkki: MongoDB + data + visualization
http://openlife.cc/blogs/2014/august/mean-hackathon

Polymer + AngularJS helposti: Yeoman

Olen pyöritelly vähän Polymeriä koska se kiinnostaa kovasti. Kyseessä on siis uuden sukupolven JavaScript-ui kirjasto jossa pääjuju on komponentisointi, uudelleenkäyttö, laajennettavuus – mutta vaihteeksi UI puolella.

Ongelmana on että se ei ole yksinään kovin vahva – se keskittyy vain yhteen asiaan eli komponentteihin. Frameworkit kuten Angular ovat suosittuja koska sieltä löytyy järeästi arkkitehtuuria tarpeeseen kuin tarpeeseen.

Olen käytellyt Yeomania aiemminkin, mutta aika ajoin huonoin kokemuksin. Nyt päätin testata sitä tässä yhteydessä vielä kerran, ja vaihteeksi pelittää hienosti. Tässä tarinaa vähän elementeistä ja kokemuksista.

Pohjalle koneeseen on syytä asentaa Node.js ja npm, niiden avulla pystyy sitten asentamaan kaiken muun. Vakityökalut mitä asennan tyypillisesti ensiksi, ovat esim. bower ja grunt, ja tässä yhteydessä yeoman. Ne voi asentaa globaalisti esim. näin:

npm install -g bower grunt yo

Nyt pitäisi komentoriviltä onnistua em. komennot, esim. bower, yo, grunt. Jos ei onnistu, todennäköisesti poluissa on vikaa. Esim. omassa Windows 8 koneessani piti lisätä PATH perään c:\users\munprofiili\AppData\Roaming\npm kansio johon nämä oletuksena tuikataan. Ja jo pelittää.

Seuraavat ohjeet on apinoitu suoraan lähteestä http://www.html5rocks.com/en/tutorials/webcomponents/yeoman/

Asenna polymer generaattori näin:

npm install -g generator-polymer

Seuraavaksi tehdään kansio, ajetaan generaattori, ja käynnistetään serveri:

mkdir MunPolymeeri

cd MunPolymeeri

yo polymer

(Tässä välissä voi vastata että juujuu, core ja paper kaikki mukaan vain!)

grunt server

Ja jos menee yhtä sulavasti kuin mulla, niin käynnistyy livereload serveri, joka avaa selaimen, ja lataa Angular+Polymer softarungon. Tämä on siitä metka että sitä voi haluamallaan tekstieditorilla muokkailla ja samantien kun tallentaa, se lataa muutokset ruudulle.

Olen pyöritellyt muutamia mukavia editoreita. Kaupallisella puolen varmaan IntelliJ WebStorm on kovimmasta päästä – mutta se on omaan makuuni joko turhan raskas/jäykkä/rajoittunut tai sitten en vain osaa käyttää sitä. Pidän kuitenkin keveämmistä, nopeammista ja notkeammista välineistä. Tähän asti olen käyttänyt ihan Notepad++ editoria, sopivin plugarein varustettuna. Mutta nyt aloin innostumaan Sublime Text -editorista, ja se pysyy testissä kunnes osaan sanoa onko se parempi vai huonompi kuin notepad++. Ominaisuuksia on ainakin enempi, tosin rahaa pitäisi pistää peliin jos alkaa tosissaan käyttämään. Siinä on aina pieni kynnys, onneksi kokeilemaan pääsee ilmaiseksi. Myönnettäköön myös, että Sublimen lisenssimalli on perin reilu.

No niin, siinä on toimiva softarunko pyörimässä, ja meillä on editori. Mitäs seuraavaksi? 😉

 

Linkkivinkkejä:

http://www.sublimetext.com/

http://www.jetbrains.com/webstorm/

http://notepad-plus-plus.org/

JAX-RS ja Swagger: Helposti dokumentoity REST API

Hetken aikaa jo on tykyttänyt mietintämyssyn alla miten REST rajapintoja voisi helposti dokumentoida – WSDL kun sieltä uupuu (Ja WADL:ia ei kukaan halua). Kuitenkin pitäisi pystyä kertomaan ja rekisteröimään missä osoitteissa on palvelua, mitä ne tekevät, miten niitä kutsutaan, jne, muutenkin kuin testeillä ja esimerkeillä.

Törmäsin mukavaan jersey-yhteensopivaan laajennukseen nimeltä jersey-swagger. Sovitin tätä Glassfishin versioon, jossa pyörii Jersey 2, ja sainkin jotain aikaan. Tässä muistiinpanoja:

Käyttöönotto vaatii muutaman askelen: Ensiksi täytyy Mavenissä tai Gradlessa ottaa käyttöön swagger jersey versiolle kaksi. Samalla on tuikitärkeää määrittää pari exclusionia, tai serverille päätyy duplikaatteja hieman eri versioista ja tulee mukavia poikkeuksia logista. Tässä toimivaksi testattu dependency Glassfish neloselle:

 <dependency>
   <groupId>com.wordnik</groupId>
   <artifactId>swagger-jersey2-jaxrs_2.10</artifactId>
   <version>1.3.7</version>
   <exclusions>
     <exclusion>
       <groupId>org.glassfish.jersey.media</groupId>
       <artifactId>jersey-media-multipart</artifactId>
     </exclusion>
     <exclusion>
       <groupId>org.glassfish.jersey.containers</groupId>
       <artifactId>jersey-container-servlet-core</artifactId> 
     </exclusion>
   </exclusions>
 </dependency>

Hyvä tarkistaa tässä välissä että vanhat palvelut edelleen toimivat, jos niitä on. Seuraavaksi rekisteröidään Swagger servicet. Tämän voi tehdä xml:ssä – mutta itse käytän ResourceConfig-luokkaa ja annotaatioita:

@ApplicationPath("rest")
public class ApplicationConfig extends ResourceConfig {
public ApplicationConfig() {
packages("my.own.resources","com.wordnik.swagger.jersey.listing");
 }
}

Noin, sieltä aktivoituu tosiaan pari resurssiluokkaa, automaattisesti /rest/api-docs osoitteella. Seuraavaksi rekisteröidään Swagger servlet. Tämänkin voi tehdä annotaatioilla mutta kun sattui olemaan vielä web.xml (se on ainoa paikka jossa voi tehdä distributable-setin ha klusteriin) – tein sen siellä näin:

 <servlet>
 <servlet-name>JerseyJaxrsConfig</servlet-name>
 <servlet-class>com.wordnik.swagger.jersey.config.JerseyJaxrsConfig</servlet-class>
 <init-param>
 <param-name>api.version</param-name>
 <param-value>1.0.0</param-value>
 </init-param>
 <init-param>
 <param-name>swagger.api.basepath</param-name>
 <param-value>http://localhost:8080/rest/api-docs</param-value>
 </init-param>
 <load-on-startup>2</load-on-startup>
 </servlet>

Nyt alkaa jo melkein tapahtumaan. Seuraavaksi pitää varustaa ainakin yksi palvelu @Api-annotaatiolla, metodeille voi pistää @ApiOperation, ja parametreille ja paluuarvoille @ApiModel annotaatioita. Jotta saat jotain näkyviin tarvitset ainakin yhden @Api-annotaatiolla varustetun palvelun, jolla on ainakin yksi @ApiOperation annotaatiolla varustettu operaatio.

Tähän tapaan:

@Path("/pet")
@Api(value = "/pet", description = "Operations about pets")
@Produces({"application/json", "application/xml"})
public class PetResource {
  ...
@GET
@Path("/{petId}")
@ApiOperation(value = "Find pet by ID", notes = "More notes about this method", response = Pet.class)
@ApiResponses(value = {
  @ApiResponse(code = 400, message = "Invalid ID supplied"),
  @ApiResponse(code = 404, message = "Pet not found") 
})
public Response getPetById(
    @ApiParam(value = "ID of pet to fetch", required = true) @PathParam("petId") String petId)
    throws WebApplicationException {
@ApiModel(value = "A pet is a person's best friend")
@XmlRootElement(name = "Pet")
public class Pet {
  @XmlElement(name = "status")
  @ApiModelProperty(value = "Order Status", required=true, allowableValues = "placed,approved,delivered")
  public void setStatus(String status) {
    this.status = status;
  }
  public String getStatus() {
    return status;
  }

Sitten voitkin käynnistellä serverin, ja kokeilla mitä löytyy kontekstin alta osoitteella /api-docs, /api-docs/myservicename, jne – tässä tietysti myservicename on joku palvelu johon olet noita Swagger-annotaatioita ripotellut.

Tuolta löytyy myös esimerkkiä live-sisällöstä, niin kauan kuin se tietysti on pystyssä:

http://petstore.swagger.wordnik.com/api/api-docs

Näyttäisi tämmöiseltä:

{"apiVersion":"1.0.0","swaggerVersion":"1.2","apis":[{"path":"/pet","description":"Operations about pets"},{"path":"/user","description":"Operations about user"},{"path":"/store","description":"Operations about store"}],"authorizations":{"oauth2":{"type":"oauth2","scopes":[{"scope":"write:pets","description":"Modify pets in your account"},{"scope":"read:pets","description":"Read your pets"}],"grantTypes":{"implicit":{"loginEndpoint":{"url":"http://petstore.swagger.wordnik.com/oauth/dialog"},"tokenName":"access_token"},"authorization_code":{"tokenRequestEndpoint":{"url":"http://petstore.swagger.wordnik.com/oauth/requestToken","clientIdName":"client_id","clientSecretName":"client_secret"},"tokenEndpoint":{"url":"http://petstore.swagger.wordnik.com/oauth/token","tokenName":"auth_code"}}}}},"info":{"title":"Swagger Sample App","description":"This is a sample server Petstore server.  You can find out more about Swagger \n    at <a href=\"http://swagger.wordnik.com\">http://swagger.wordnik.com</a> or on irc.freenode.net, #swagger.  For this sample,\n    you can use the api key \"special-key\" to test the authorization filters","termsOfServiceUrl":"http://helloreverb.com/terms/","contact":"apiteam@wordnik.com","license":"Apache 2.0","licenseUrl":"http://www.apache.org/licenses/LICENSE-2.0.html"}}

Törmäsin myös toiseen aika metkaan standardiin – ALPS. Sitä näyttäisi osaavan Spring Framework hyvin, mutta ainakan nyky-jerseystä ei löytynyt helppoa ratkaisua siihen. Pidän tätäkin kuitenkin silmällä. Looking good!

http://www.dzone.com/links/r/spring_data_rest_now_comes_with_alps_metadata.html

http://alps.io/

Näistä linkeistä löytyy vähän lisää ideoita. Varovaisuutta vanhemman Swagger-version kanssa!

https://github.com/wordnik/swagger-core/wiki/Java-JAXRS-Quickstart

 

 

Android L Uusittu Camera2 API

Tuleva Android L on monessakin mielessä hyvin mielenkiintoinen, mutta taas kerran yksi itseä kiinnostava asia on parannettu Camera API.

Olemassaollut rajapinta kameran käyttöön oli kohtuullinen, mutta hyvin rajoittunut. Sillä pääsi käsiksi kuvaan joka oli otettu, mutta ei esim. kuvaan suoraan kamerasta tulevana, ennen sen tallennusta – jota joskus itse kaipasin. Tyypillinen kamerakoodi oli kuvan käsittelyä sen oton jälkeen.

Uusissa laitteissa on ensinnäkin paranneltu latenssia ja rautapuolta, mutta Android L tuo mukanaan myös Camera API version 2 – se löytyy paketista android.hardware.camera2 (ei kovin suuri yllätys 😉

Sieltä löytyy mm. CameraManager, CameraDevice, CaptureSession, CaptureRequest, ja CaptureResult luokat, jotka antavat jo nimillään kuvaa siitä millä tasolla liikutaan.Camera data model

Ensimmäinen palikka on yleensä CameraManager, jolta saa tietoa saatavilla olevista kameroista. Sen openCamera-metodilla pääsee käsiksi CameraDevice instanssiin, joka edustaa yhtä kameraa.

Seuraavaksi tarvitaan kohteita, joihin kameran esikatselu/tallennus ohjataan. Ne rekisteröidään kameralle ennen kuin sillä voi juurikaan muuta tehdä. Näitä löytyy Surface-rajapintojen alta, esim. TextureView (esikatselunäyttö), MediaRecorder (videon tallennukseen), MediaCodec, ImageReader (kuvien tallennus), RenderScriptAllocation .(YUV prosessointi). Näiden kohteiden koot pitää säätää käytössä olevan kameran mukaan.

Seuraavaksi kutsutaan createCaptureSessions-metodia, joka saa parametrinaan em. kohteet – ja kutsuu valmistuttuaan StateListener-olion onConfigured-metodia (initialisoinnissa voi mennä hetki aikaa).

Seuraavaksi, createCaptureRequest-metodin kautta pääsee käsiksi CaptureRequest-rajapintaan. Parametrina annetaan yksi seuraavista: TEMPLATE_PREVIEW, TEMPLATE_RECORD, TEMPLATE_STILL_CAPTURE, TEMPLATE_VIDEO_SNAPSHOT. Taas kerran vakioiden nimet ovat hyvin kuvaavia.

Tämän CaptureRequest-rajapinnan kautta voidaan päästä käsiksi mm. valkotasapainoon, sisäänrakennettuihin efekteihin, ja salamaan, ISO arvoon, jpeg metadataan, valonmittaukseen, valotuksen säätöön, kuvanvakaukseen, jne.

Seuraava piirre kiinnostaa etenkin itseä, kun järkkärillä valokuvaus kuuluu myös rakkaisiin harrastuksiin: Täältä pääsee käsiksi myös autofocus- ja autoexposure-toimintoihin, ja niitä voikin säätää manuaalisesti.

Varsinainen kaappaus tapahtuu session-instanssin capture-metodilla, välittäen samalla sekä request, että CaptureListener callback-olio parametreina. Näin saat tiedon kun kuva on otettu – kiitos asynkronisten viiveiden jne.

 

Rajumpia päivityksiä ovat mm. burst mode, hdr+, mahdollisuus kaapata kuvia sillä tahdilla mihin rauta pystyy (Esim. Nexus 5 30 fps 8-megapikselin kuvien valokuvaus).

Koodiesimerkkejä perästä jahka joskus kerkisi huvikseen taas koodailla 😉

Mutta onhan noita jo Interwebbi pullollaan. Esim. tuolta: https://github.com/googlesamples/android-Camera2Basic

 

Tuolta lisätietoa:

https://source.android.com/devices/camera/camera3.html