I love UI. I REALLY do. Not UI but design in general. I love it so much that Graphic Designer was the other option I was considering before starting university. I endeed choosing engineering and the reason is simple: although at that time I was more skilled with a pencil (drawing has been my greatest hobbie since I was 3) some early approaches to programming alowed me to see that programming is a very creative form of expression.
If you have read some of my posts regarding Android you may have noticed I’m a big time fan of the observer pattern. It’s with a little shame I have to admit I came to know of RXJava no long ago and since I started using it I’ve been falling in love with it more and more.
I’m also a big fan of moving any computation away from Android’s main thread (AKA UI thread) to build apps as fluid as I can. RXJava is the perfect tool to achieve this.
I won’t enter in the details of what RXJava is and the details of the Observer Pattern (RXJava is so much more than that). Instead I wanted to share with you how I jumped from the theory to the practice: CODING !
I’m going to be upgrading the same idea I’ve visited in the past but using ASP.NET Core this time. The plan is to structure a very simple architecture that allows us to build a web application above it. For this article I’ll be using a very simple Repository Pattern as a base for a ASP.NET Core Web Application.
The sample solution will have 3 projects: Domain, Data Access and Web Application layers. This time I will leave out the Business Logic layer to make this tutorial simpler and cleaner. You will be able to add your managers and services easily later.
We have gone a long way with the Application Drawer pattern on Android but there is always stuff to cover. On the previous posts we covered how to create a very simple and and then a more complicated one.
This time I want to show you how to deal with configuration changes and the application drawer.
A “configuration change” is an event that will destroy and recreate the Activity object. This means the views and variables of this object will be cleared. Following the samples we have been discussing, this means your Application bar state will be affected since we change how it behaves depending on the type of fragment we are in (a root fragment with the hamburger, or a sub section fragment that uses a back arrow instead).
֍ Looking for ASP.NET Core ? follow this link
The code for this solution in this link
I’ll put Android development aside for a moment to write an update of an old entry related to ASP.NET and MVC.
Normally when the time goes by not only technology changes; New framework versions are released and us (developers) learn new tricks on how to use them. ASP.NET MVC is no exception.
I want to do the same exercise I did before but this time with a few tweaks and some additions (Unit of Work). I’ll show you how to build a very basic architecture for a fully functional ASP.NET MVC5 / WEB API application. Nowadays this can be called a full stack development. This application will be based on an N-Layered architecture:
Hey, I’m adding more meat into these series of fragment navigation tutorials. If you have been following my past entries you should have some knowledge on the Application Drawer design pattern and fragment navigation. If not, go and take a look at this post.
So far I have shown you how to create a very simple app: a home screen that allows to navigate to other sections via the drawer. Once you have reached one level of navigation the drawer is no longer accesible and you will have to navigate back to the home to reach it again.
Hey, this time I want to write a bit about the Drawer design pattern in Android. If you have played with this I’m sure you have faced one or more issues regarding navigation (and the fragment’s back stack). I believe this tend to happen because we are used to let Android navigate those view stacks but when you transition to fragment transactions you are forced to pay attention to this.
You will find the code for this blog post here:
Note: this article has a “part 2” that improves on this code. You should still go through this post first.
Hey, I know it’s been a while but as usual, my excuse is I don’t have enough time to write here 🙂
This time I’d like to update some old concepts with new technologies: I’ve been working on the Android platform for a while and things evolve way too fast ! This tutorial will help you build some nice structures to fetch data from RESTful web services.
This article will not cover all the HTTP Verbs but I have laid the bases for you to easily implement them. Like my other articles, I’m going to assume you have background on Android development and you understand some programming patterns (specially the Singleton pattern).
I’ve decided to write a series of tutorials aimed to create modern android apps using the concept of material design. As usual I’ll go baby steps but I will also assume you have knowledge on the platform and specially on Java programming. OOP is a must as well.
This few paragraphs will be dedicated on the focus of the app, or in other words what the app should do. It has to be generic enough so the sample is helpful to a broader audience but not to much to avoid unnecessary code complications.
For now we will do a simple product catalog that will be using the specs detailed on the material design guide by Google.
It’s important to state that we will not see a lot of material design during the few first chapters ! We will get there in time !
you are still here ? seriously check the new version !
today I had the chance to play a little with the new ASP.NET Identity and the OWIN paradigm. Let me tell you, it was really confusing (and to be honest, I still feel lost on so many things !), and I believe this is because I haven’t found a good reading about how to proceed. I know the baked solutions have all you need but still…