Forem: Miguel Rodriguez

How much JavaScript should I be familiar with before getting into React?

Miguel Rodriguez — Fri, 02 Aug 2019 14:52:49 +0000

Hi, I began to learn HTML, CSS, and JavaScript for front end development a month ago. I consider myself a JS beginner, so far I have only completed freecodecamp's JavaScript course about oop, algorithms and data structures.

How much JavaScript should I know or which JS concepts should I be familiar with before getting into a JS framework like React?

Tips to be a good leader?

Miguel Rodriguez — Thu, 17 Jan 2019 17:28:36 +0000

So, to begin the year, I was just assigned as Project Owner of a mobile app we're developing at the company I currently work for. Which is a big deal for me since I'm a self-taught developer and started working only a year ago, but apparently the managers are happy with my performance (yey :D).

My main responsibilities involve Sprint plannings, Sprint reviews organizing daily Scrum meetings, of course communicating with the team to see that everything's alright, and getting in touch with the client from time to time for updates and requirements.

What advice do you guys have to be a good leader?

What soft-skills and practices do you think a leader should have to achieve a good working environment and getting the job done?

Tips to keep your Android app project organized

Miguel Rodriguez — Mon, 14 Jan 2019 17:52:02 +0000

The importance of an organized code structure

It's all about readability. Big projects can be difficult to organize due to the amount of classes, resource files and libraries used. Having an organized code structure involves separating classes into different packages according to their purpose and having proper names for your resource files.

This post should be useful if you develop Android apps using either AndroidStudio or IntelliJ.

Package name for your Android app project

Quick note, when you're just creating a new project you will be asked to choose the package name for your project. As the Android documentation states, the correct way to name your project is com.company.appname, this follows the normal Java package naming conventions.

File types

Some of the file types that we work with in an Android includes classes (ClassName.java or .kt) and resource files (activity_main.xml) such as drawables, layouts, values, etc.

Classes and resource files are separated by AndroidStudio (or IntelliJ) by default. You can find classes in app/java/com.company.myapp/ and resource files in app/res. However, as I mentioned before, big projects can have a lot of classes with different purposes, and a lot of layout resource files. Keeping them orginized its important to have a mantainable project.

Classes

Organization and naming tips

There are a lot of classes, with different purposes, that you can have on a project. Surely you'll have Activities, Fragments, Models for your objects, Adapters, and depending on your app's reach, Network requests, Services, Wrappers (which I call Response), etc.

As for the class names, I like to follow this guide and end the name with the name of the component (Activity, Fragment, etc.).

Android Studio lets you create packages after app/java/com.company.myapp/ so you can use them to keep classes separated according to it's purpose. This will help you and your coworkers navigate through your project. To crate a package just right-click on the package name -> New -> Package.

Activities: Contains yout project Activity classes. An Activity name example can be LoginActivity.
Fragments: Contains your project Fragment classes. A Fragment name example can be UserRegisterFragment
Adapters: Contains Adapter classes for your ListViews (or RecyclerViews). Adapters should be reused as much as possible to prevent repeating code. (DRY :) ) An Adapter name example can be SongsAdapter.
Network calls: This depends on your preference I personally name this package as HttpRequest and contains the classes associated with Retrofit2 to perform REST calls, as well as the API interface where I define the endpoints. Class names can vary, in my case, I usually have the RetrofitServer.java, MyAppAPI.java and APIUtils.java classes.
Models: The Model package is usually used to store the classes to map objects from a network request, or simply to create objects in other classes. Since it looks weird to initialize an object as 'HouseModel house = new HouseModel()' I take out the component name from it and keep it just as House.
Wrappers or Response: This package contains classes that serve as wrappers when performing network calls, and usually contains only one object pointing to a Model class. Same as with Adapters, try to reuse as much of these as you can. I usually name this classes with the same name as the Model class it'll wrapp, but with 'Response' at the end, for example, HouseResponse.
Utils: Any other classes that you cosnider that don't require their own package, from simple things as a class that creates some special margin you wanted for your TextViews to Services or Singleton classes to manage user sessions.

Here's a quick exampe of how my packages look.

Resource files

Types of resource files

Resource files can be found in the res folder. There are several packages that contains resource files, some of them are: drawables (for icons, images and backgrounds), fonts, layout (for our Activities and Fragments layouts), menu (for menus such as NavigationDrawers, BottomNavigationBar, etc.), values (may contain your string, colors, dimens, styles, among other resources.

I'm going to focus on the naming conventions for layout resource files. Unfortunately, you cannot create packages or folders to save layout files as we do with classes, all of the layouts are saved together in the layout folder. That's why it's important to pick the right naming convention.

Resource files naming tips

Something that's been useful for me is to name my layout resource files as: 'component_description'. For example, the layout for your LoginActivity would be named as activity_login. A UserRegisterFragment layout would be named fragment_user_register_activity. And same for adapters, dialog fragments, and even menu resource files (for example, for a BottomNavigatioMenu: bottom_nav_main_menu). This way you only have to look for the component and then for the description of your layout. Think of it as sorting them.

Here's an example:

Even though I didn't chose the best names for my layout files (still needs refactoring), I know where to look for a Fragment layout, for my DialogFragment ones, as well as Activities and Adapter.

Conclusion

That's it for this post! We've discussed the importance of keeping and organized project and how to do it with simple every-day practices. If there's some convention or practice that you think can be useful for code organization either for me or anyone reading this post, please share!

Twitter: https://twitter.com/MiguelDev_95

Some references

https://blog.smartlogic.io/2013-07-09-organizing-your-android-development-code-structure/

https://guides.codepath.com/android/Organizing-your-Source-Files

https://github.com/ribot/android-guidelines/blob/master/project_and_code_guidelines.md

ConstraintLayout beginners guide Part I: Designing a repsonsive UI for Android apps

Miguel Rodriguez — Thu, 10 Jan 2019 00:47:35 +0000

Since I've been learning how to develop mobile apps for Android, I would like to write posts about some useful things I've run into. It helps me to organize my ideas and it can be useful for developers who are getting started with Android development.

In this post I will talk about the advantages of ConstraintLayout, a tool that completely changed the way I design views for Android apps. Some of the features that I'll get into are:

ConstraintLayout Overview
Center Views
Chain Views

In Part II, I'll make sure to cover Guidelines and other features.

What is ConstrainLayout and why do I need it?

There's a lot of devices with the Android OS with different screen sizes, and this can be an issue for developers...

As we know, the Android OS runs on a great variety of smartphones. According to Statista's article about OS worldwide distribution around 85% of the smartphones in the world run on Android and there are thousands (maybe millions) of different models running with this operating system.

This causes a well known issue for Android developers: building an app that run smoothly and look good in as many devices as possible.

There are ways to address this issue. Goolge released Constraint Layout in the 2016 I/O and this method has been widely recommended by and for developers to design responsive UI.

What is Constraint Layout?

As the official Android developer documentation states, ConstraintLayout allows developers to create complex layouts with a flat view hierarchy, which means there's no need to use nested ViewGroups, which helps for build efficency, memory usage and the device will take less time to create the view.

If used correctly, ConstrainLayout also simplifies designing views that look good when the screen is in landscape mode. It's all about knowing how to connect views with their parents and siblings.

In this tutorial I'll address some of the main features that ConstraintLayout provides using Android's LayoutEditor.

To access the LayoutEditor click on the 'Design' tab.

LayoutEditor overview

Now that you're in the LayoutEditor, you can see I've marked some of the most important sections. From left to right you can see:

-Palette: The palette contains most of the views you may need in your layout. To add a view (such a button) just find it in the Palette and drag it to your Component Tree. For some other views (from example views that come from libraries you added) you may need to go to the Text tab (xml) and add it manually.

-Component Tree: The component tree shows the hierarchy of your nested layouts (if required), the views inside each layout, the views' id and some other features like guidelines or barriers (we'll talk about them later).

-Device you're currently using: I considered it important because sometimes you want to see how the layout changes on bigger or smaller smartphones. The LayoutEditor provides some options to do this. And on the left, you can choose to change the orientation of the screen to landscape.

-Attributes: In this section you define the attributes (such as background, color, style, etc.) of a selected view, just like in the xml. To access more attributes, click on the double-arrow icon on the right. Another important part of Attributes is the square with dots/lines. You'll use it to define constraits and margins for a selected view.

ConstraintLayout features

Now that we've located our tools, it's time to get into what we can do with the LayoutEditor and ConstraintLayout.

The first thing to notice, is the dots that appear on the top, bottom, left and right of each view. By clicking on them and dragging the mouse, you can connect with another views to build your layout.

MatchConstraint, WrapContent or Fixed

When using ConstraintLayout you get to decide the way your view's boundaries (width and height) will be defined. We can edit this by clicking the icons (which might be arrows, a line or a zig-zag line) inside the square that represents our view or simply by editing the height and width attribures. From left to right:

Match Constraint: Match constraint will stretch your view to it's connections. As you can see in the image below, I've connected textView to textView2, and I've selected match_constraint as the width of textView. In the second image, I added a margin of '24' to the right of textview.

Remember that the more constraints you have in a layout, the more responsive it becomes.

Wrap Content: A common attribute on most ViewGroups. This simply means that te ViewGroup will be the size as its content. If we're talking about a TextView, the width will be as long as it's text.

Fixed: By choosing Fixed you define the width and length of the view. It's recommended to use dp over px or in as units, because it considers the density of the smartphone's screen and adapts the view to it. Set it by simply editing the height and width attributes.

Note: Notice that you can choose different options for height and width, for example, your width can be defined by MatchConstraint while your height uses WrapContent, just like in any other ViewGroup.

Center a view

We can center a horizontally or/and vertically by right-clicking it and choosing the center option.

You can also center a view considering the connected views, for example:

In this image, the texView at the left is centered horizontally considering the left constraint (parent) and the right constraint with textView2 (sibling). I've also have added a margin of 16 to both sides.

Chain Views

Using chains is helpful when you have several consecutive views, for example, when you have three buttons at the end of your layout, or when you have a Fragment or Activity for user registration in your app. You can use either vertical or horizontal chains by selecting the veiws you want to chain in your component tree, right clicking and selecting chain.

You can style a chain of views in 4 different ways:

Spread
Spread Inside
Weighted
Packed

Spread: This is the default style when you choose the chain option. First I centered the three buttons vertically, then I selected the horizontlal chain option.

Spread Inside: To use this option, you'll need to edit the attribute of 'layout_constraintHorizontal_chainStyle' directly form the xml. This is the result of applying a spread_inside horizontal chain to our buttons:

Weighted: When you choose either spread or spread_inside as style, you can set weights by editing each view 'layout_constraintHorizontal_weight' attribute. It works just as the 'layout_weight' in LinearLayout. In order for this to work, you must set the width attributes to match_constraint.
In this image, I've set the width of all of the buttons to match_constraint, and I've added a layout_constraintHorizontal_weight of .5 to the first button and .25 for the other ones, notice how the distribution changes.

Packed: To pack your views, you'll need to edit the attribute of 'layout_constraintHorizontal_chainStyle' (just like with spread_inside) and set it to packed. This is how packed chained views look like:

That's it for this post! any feedback from more experienced developers is always welcome. I'll make sure to upload Part II with more features and also brief tutorials of other Android Development topics.

Happy coding.

I'm happy that I'm not always happy with my code

Miguel Rodriguez — Tue, 01 Jan 2019 11:15:41 +0000

This year has been amazing for me, even though I graduated as a Biomedical Engineer, I had the opportunity to enter to the world of programming, and discovered my true passion developing mobile applications as an Android engineer, and I have to say... I never tought that I would be enjoying myself so much at work.

As Junior developers, we have to be aware that it's very likely that we're not the smartest (or more capable) people in our office, this is fine, I think that everyone goes through this at some point. We have to use our 'status' as beginners to learn as much as we can from other developers, and of course, from our own mistakes. Use this time in which the company consider you as junior/beginner to try different things and fail, and use this lessons to keep improving.

In this post, I will address how important it is to acknowledge that even in our best work and even on the simplest implementations, there's always something we could have done better, more efficient, more readable, or just cleaner architrecture-wise. This realizaton will make us grow faster and better as developers. Please feel free to comment and/or discuss how you agree or disagree with what I wrote.

Make sure you understood that tutorial

As a self-taught developer I had to learn by watching tutorials and straight up coding. Watching tutorials can be deceptive. Yes, following through the tutorial for some implementation will help you get the work done, but a common mistake that we beginners can make (or at least that I made) is to just copy whatever the instructor is coding without understanding what the program actually does. Make sure you understand what's happening, and if you don't, go deeper and start reading and learning about that method or class that you wrote but have no idea what it actually does. When the time comes that you need to implement something similar, you will know how to do it, how it works, and now you will be able to explore other options and compare them to choose the one that makes your code better in every aspect.

Ever been ashamed of your past work? Perfect. You're better than you were when you wrote that

Do you ever look back to your past work? Some past projects that you maybe didn't finish? Ever had the time to read a bit of that code you wrote? If you have, it's very likely that you've felt ashamed about it (I have). Feeling bad about your past code isn't bad, on the contrary, if you, a Junior deveoper, are able to recognize your mistakes and you feel capable to correct them, then I have good news for you, you're improving. The important thing is to be honest with yourself and learn to acknowledge when something you did was terrible and needs a clean up, or when it was ok and could've been done better.

Read and learn how it could've been done better

Now that you've identified where your code can improve, it's time to start learning! It's very likely that we make the same mistake of implementing a solution fast just to correct or finish some feature, and this will lead us to hating our code in the future, so we can avoid this by checking the correct implementation of things in resources such as Youtube, Stack Overflow, Github, etc. or asking our more experienced colleagues how would they do it, and why. Remember that is important to understand what we're writing!

Pass on what you've learned

Wise words from Master Yoda. Now that you're capable of recognizing and correcting your mistakes, it's time to help other get through them. As Junior developers, we don't always have te opportunity to help out our coworkers since we're not their first option when they need help. But when you get the chance, do what you can to help them out. Being able to help out others out of experience is one of the best things we can do, it makes us feel how we're getting better each day, and it makes our coworkers and managers realize that we are capable of taking on more responsabilities and challenges. And the cycle of implementing, failing and learning shall continue.

There's a way to do it better - find it.
-Thomas A. Edison

What I've learned in my first year as an Android developer. Part I

Miguel Rodriguez — Thu, 22 Nov 2018 01:53:34 +0000

I'm a self-taught developer and I don't have a lot of experience yet, but the last year has been really life-changing for me since I started getting into software development, specifically for Android applications.

Still, I would like to share what my first year as a developer has taught me with this community, and write about what I've learned and what I think are some important aspects to consider when getting started into Android development.

I'll be attaching some useful resources that have helped me.

In this post I will cover:

Resources to get started.
Considering different screen sizes.
Programming languages (Java/Kotlin).
Naming conventions for layout resource folders and class packages.

Please, if you're a more experienced developer or have a more complete knowledge of Android development and it's best practices, feel free complement and/or share how you agree or disagree with what I'm including in this post. Any comments that would help me or anyone reading this is welcome!

There are a lot of online resoures to get started

When I decided I wanted to develop mobile apps for Android, the first thing I did was to look for online courses. This approach is accessible, you can go at your own pace, and you can even skip some lessons if you don't feel like covering them at the time. I got recommended Udemy's The Complete Android Oreo Devloper Course. The course is great, it's for people who has zero coding experience (so it was perfect for me at the time), and even if you have experience, it's a great introduction into the Android environment. While I was taking the course I was also working on a side project, so it helped me a lot to apply the concepts I was learning into an actual application idea I had.

While I was watching the content of this course, I was also taking Java in Depth: Become a Complete Java Engineer! which helped me to get a deeper knowledge of the language and to not being stuck learning just the basics I needed for Android.

Other course that I can recommend, and that I'm taking on now it's Google's free Developing Android Apps with Kotlin, available in Udacity. This one requires a bit of previous programming experience and knowledge of Android Studio, but it's very straightforward and covers the fundamental topics to get started and develop apps.

YouTube videos and tutorials are also a great resource to learn specific features and implementations. There's almost always a video explaining how to do exactly what you want for your mobile app.

Getting stuck and having a hard time understaning some things is part of the process. I've learned that 95% of your questions have already been asked and answered in sites such as Stack Overflow, GitHub, or in the Official Android Developer documentation.

Don't forget to consider different screen sizes...

As you may know there are thousands of different phones that use the Android operating system. Even if you're aware of this, it may not be the first thing you consider when you're just getting started learning and building apps.

One of the first apps I made had a complex grid and some images on one of it's screens, and while I was building it I was testing it on my phone, so of course I was designing it so it would look good on MY phone.
When I uploaded it in a friend's phone, SURPRISE! I realized how horrible it looked on other devices, the grid and the images didn't even fit the screen and it was kind of embarrasing. That was the first time I struggled with srcreen sizes and realized that it's a VERY important factor to consider when building apps for Android. Be sure to choose the right ViewGroup(s) and design for different devices.

Choose your ViewGroup wisely

A ViewGroup is the container of the elements (Buttons, Texts, TextInputs, Images, etc.) in your screen and it's important to pick one according to how your content is going to be organized. Mixing a lot of ViewGroups or using them incorrectly can (and will) make your app look different (sometimes horrible) in other devices' screens that maybe you didn't considered while designing the UI.

Some of the most popular ViewGroups are:

Linear Layout
Relative Layout
Constraint Layout
Frame Layout

There are a lot more, which are used for other specific cases. Be sure to know them and choose the right one for your layout.

In Android Studio, you can pick several different devices to get and idea about how your UI will look in said device.

Creating layout.xml files for different screen densities

Other way to approach this issue is to generate up to 4 or 5 .xml files for the same layout to support different screen sizes.
For example, if you have a main_activity_layout.xml, you may have to create files such as: main_activity_layout.xml(mdpi), main_activity_layout.xml(hdpi), main_activity_layout.xml(xhdpi), etc.

This lets you to have different sizes for views, such as buttons, for the layout.xml(hdpi) than the size of the same button you have in layout.xml(xxhdpi). The app will identify the device's density and pick the layout file for said density.

Here's and example of how your layout files would look like in your res/layout folder:

Java or Kotlin?

Both are good for Android development, I've worked with both of them and each have it's pros and cons. However, if you're a total beginner in programming and/or Android development, this is what I, based on my short experiece, would recommend:

Get started with Java

I began programming apps with Java, and I would recommend that if you're a beginner (like me) you do as well.

The main reason is that Java is still used a lot for Android development, and a lot of resources are still documented in it. It helped me a lot to find documentation, open source resources, and Stack Overflow answers for Android development topics in Java. So I think it's easier to get familiar with the whole Android environment when you find support for your doubts or documentation in the language you're using.

Learn Kotlin

I recommend to learn and use Kotlin when you feel comfortable with basic functionalities and implementations for Android, such as handling buttons, listeners, using methods, creating classes and functions, etc.

The way I see it, Kotlin is the present and future of Android development. Most of the new documentation and tools are made and documented to be programmed with Kotlin. If you've watched the latest Android Dev Summits almost all of the content is explained in Kotlin, and most of the documentation is already updated to Kotlin.

A lot of job positions that I've seen are looking for developers who have worked with Kotlin or are at least interested in learning it.

Kotlin has proven to be a powerful languange that makes coding apps for Android faster and cleaner.

Naming your class packages and layout resources

Having an organized project can be not 100% intuitive. If you're working on a big and complex project you don't want your clases to be al mixed one after another. Your classes have different funcionalities in your project, some may be simple Activities or Fragments, others handle your http requests, and others may be adapters for your LisViews, and so on...

You want your files to be organized, I'll share what I think it's a simple and effective approach to work on an organized project.

For classes:

I personally like this organization where you have separate packages for Activities, Fragments, Adapters, API methods for http requests, and some Util classes for helper methods. This has helped me a lot to keep a more organized project and to know which classes I can reuse in different parts of my project.

For layout resources:

The link above also covers what I've found is a good way to keep your layout files organized. Since you can't separate your layout files in packages or folders as in clases, keeping a simple convention of naming activity_your_activity_name.xml can help you find them easily if you have a lot of layout files.

Conclusion

I've found programming Android apps to be very fun and useful! I´ve really been enjoying myself in a way I've never had while working.

Almost everyone has a smartphone now and the idea of creating for any kind of person in the world is pretty exciting, either if it's a game or an organization app, or something that addresses a social issue or solves a problem in healthcare. The possibilities are infinite!

Being a self-taught developer, or trying to learn something by yourself is not easy, but it doesn´t have to be very hard either. Learn how YOU learn best, find support not only in communities and resources online, but also with friends or coworkers, there's nothing wrong in not knowing and/or struggling every once in a while. Remember that you're never the smartest person in the room, and if you are, then maybe you're in the wrong room.

Keep learning and happy coding!