Profile cover photo
Profile photo
Fernando F. Gallego
1,044 followers -
GeeK!
GeeK!

1,044 followers
About
Posts

Post has attachment
drawn with a touchpad :D

Post has attachment
If you are developing tizen apps, join my community to share your knowledge and ask questions #tizen #samsung #development

Post has shared content
After looking for already made solutions out there and not finding a "good enough" one, been working on a way to generate Long Shadows on android, with variable angle, length and style.

It works at bitmap level so it can be used for texts, images, whatever.

I'm sure the result could be better, but my knowledge doesn't reach there. It could be implemented in pure java (slowww as hell) or C/JNI (a bit faster but not enough for realtime).
If I knew how to do it in RenderScript I'd try to see the speed comparision, but never done anythin with RenderScript so I have zero idea how to even start (hint hint, help anyone?).

#androiddev #yesthisiscomingtoADW2
Animated Photo

Post has shared content
:O
Turn your Sketch mockups into VR experiences with the newest Plugin for Sketch

Post has shared content
Finally!
Our next meetup is on July, 6th and we will have two presentations on UI architecture on Android. #gdg #android #munich

(Posted by +Markus Junginger)

I had to disable InstantRun on Android Studio 2.0, otherwise it was taking more than 10 minutes to build an app, crazy #AndroidStudio #AndroidDevelopment

Has anybody tried to replace the Nexus5 battery? I did and now the screen doesn't turn on but the phone is on (my wristband connects to it :/) 

Post has shared content
Creeeeepy! but cool!

Post has shared content
Composition over Inheritance
What it means for your Activities

So we've all heard the suggestion that we should prefer composition over inheritance. For those that haven't, the idea is classes should only inherit from classes if they can fully stand in for their parent class, not just to share some behavior (more information at [0]). Despite this, I can't count how many Android projects I've been on/seen that had some BaseActivity that all of their Activities must extend from.

This can be problematic on a few fronts. The most obvious is that when Joe Newguy comes in and adds ShinyFeatureActivity, there's nothing forcing him to make sure it extends BaseActivity. Hopefully it's caught in code review. Additionally, it prevents you from extending from any other Activity class (E.g. PreferenceActivity, ListActivity...). Many of these Activity subtypes have been replaced by Fragment subtypes, but not all. Some libraries might also need their own Activity subtype.

Somewhat more insidious is that you might have some behaviors that are used in several of your Activities, and another set of behaviors for another group of Activities. Since Java doesn't support multi-inheritance, you have no choice but to put all of the behaviors into a single base class if these groups overlap. That means reduced maintainability, and possibly some performance penalties.

It's easy to see why we like to do this. Code reuse is a good thing, right? And much of our common logic needs to happen at specific points in the Activity lifecycle. Application.ActivityLifecycleCallbacks can be a pain to work with (they're passed Activities rather than living in them) and likely need to be registered in Application.onCreate() which we try to avoid.

This is where headless Fragments come in. While a lot of Android developers think of Fragments as UI components, they're really more lifecycle components. So what do I mean by "headless"? Just that onCreateView() either isn't overridden or returns null. Essentially, these are Fragments that implement some process or control that doesn't have a UI itself.

To differentiate my headless Fragments from my View oriented Fragments, I've taken to suffixing my headless Fragments with "Helper" and other Fragments with "Fragment". For example, AnalyticsHelper would be a headless Fragment for attaching my analytics logic, while HeaderFragment shows a header View for something. This is totally optional, but I've found it helpful.

Since there is no UI for these Fragments, there is no layout ID necessary to inflate into or animations to worry about, so your factory methods can be smarter and more controlled. For that matter, they can handle adding the Fragment themselves. I've created a gist [1] that shows how to do this. In Android Studio, you can add this to the "File and Code Templates" section in settings, and when you create a new class (New -> Java Class), select it in the "Kind" dropdown.

Adding FooHelper to its parent is as simple as calling FooHelper.attach(this). You'll get compiler errors telling you if the parent doesn't implement FooHelper's callback interface, and if attach() had already been called, it will return the preexisting fragment. The gist includes overloads for framework Fragments and Activities, but switching them to use support Fragments and FragmentActivity is pretty trivial. It also includes a getParent() that is a simplified version of my FragmentUtils.getParent() gist [2].

Obviously headless Fragments are more useful than just getting stuff out of your BaseActivity. They're also great for encapsulating processes that need lifecycle callbacks (or onActivityResult(), or a child FragmentManager...). The great thing about replacing BaseActivity, though, is that now you can split up the "common" logic onto single-purpose modular components, and decide for each Activity which modules you actually need. If most of your Activities need a lot of the same modules there's no reason you couldn't write a CommonComponentsHelper to pull them in, but now you're not forced to keep all your common dependencies in one base class.

[0] http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance
[1] https://gist.github.com/keyboardr/ddf35148ca2c1a2bfbde
[2] https://gist.github.com/keyboardr/5455206

Post has shared content
Para los que no lo sabéis, este domingo empezó la *segunda temporada de Halt and Catch Fire*. En este primer capítulo parece que la segunda temporada abarcará otro tema distinto al de la primera, aunque aún no está muy claro el qué, salvo la parte de Cameron y los juegos online.

En cierto modo, parece un Cuentame como pasó en Sillicon Valley.

Los frikis-tecnólogos que no conozcáis la serie, ya estáis tardando. Es más, tiene un +Ismael Olea  approved. así que no hay excusa
Wait while more posts are being loaded