Month: August 2018

Hey everyone,

Today, I’m going to delve into the goods and bads of what is provided via the company. But, I think we should first ask ourselves what’s good and what’s bad? We have options like holidays, gym memberships, snacks, insurance, etc….

Is it a company’s holiday? Take it! It’s just one of those things that are given free to you, and plus if you are working on a salary basis it’s what you are owed via work standardization. Otherwise, if you don’t use it, then it’s gone. That time cannot be taken back.

If the company provides gym memberships for free, take it and use it! If not, then I’d first compare rates and the different offerings with other contracts to find the best deal for you. Health is an important aspect of life, but at the same time, you can also have a small gym with the activities you like at home.

Snacks? Depends. What I usually do is look through the ingredients before consuming stuff. We as developers have a problem which is sitting and staring at the screen all day already. Therefore, we need to watch our sodium, cholesterol, and sugar intake. All of this counts towards productivity. Unfortunately, there are those who would be eating chips all day; I stay as far as possible from that as I am not willing to risk my health for such junk. Think about what is best for you, and stick with that.

Insurance? This is necessary by law living in America at this time of writing, at least for medical. In fact, I opted in for an HSA this year since this is a smart way to save your money. So look at the best option for you, and then make a decision. Everything else is voluntary, but it will be worthwhile only if it’s going to be used.

And all other factors? Again, you decide what is best for you before doing anything, because before considering everything else around you, you must love yourself.

Until next time!

Brian.

Hey everyone,

A little bit before, I had posted on getting to a better solution. If you haven’t read it yet, you can find it here: http://improvisedcode.com/2018/08/29/getting-a-solution-that-is-simpler-than-what-another-person-has-posted/

Today, I am going to focus on an example of that. I came across this problem: https://stackoverflow.com/questions/3554377/handling-click-events-on-a-drawable-within-an-edittext

The answer by aristo_sh works, sure. What I see that isn’t pretty however, is that this touch event will trigger anywhere, and it will be ignored outside of the drawable. And although the check will handle the job well, there’s another problem to deal with: justification!

And what we mean by justification is how your layout draws depending on the region and language. In the solution posted above, there is no justification. aristo_sh’s solution is just checking on the right side when touched. The edge case is, what will happen with Hebrew? The event will be triggered probably within the EditText instead of the drawable! Not good…

I’ve learned that dealing with justification by using start and end instead of left and right will absolutely work for every language. However, typing up “GetEnd” or “End” didn’t come up with any result. Therefore, I knew this solution wouldn’t work for me.

So what I did instead was programmatically setup a transparent view, with twice the dimensions of the drawable that gravitates towards the end of my TextInputLayout (and in case you didn’t know, TextInputLayout is a child of LinearLayout), then set the top gravity to the negative of twice the drawable’s height before adding the view. This was great since I didn’t have to wire up any events I didn’t need for my EditText. Instead, I just had my click event for the transparent view that sits on top of the drawable.

It worked, and it was a lot simpler than the original solution. Therefore, it is assured that across all languages, this solution will also work.

Now, why is this better?

First of all, there is no checking involved. Secondly, it is just wiring up a view, and not any weird or extra EditText events. Third, it’s just another view that gets added onto a ViewGroup. Lastly, it is much easier to understand, and the next developer will certainly be happier of this choice.

Now it’s known that Google will rewrite their APIs quite soon. From now, we’ll have to see how much simpler they’ll be doing things versus the codebase that we will have to work with now, but I’m sure that there are always improvements to be made.

Anyway, I just wanted to share my two cents of what can be better. Therefore, just keep trying to find out the right way to do certain things!

Until next time!

Brian.

Hi everyone,

I’m betting many of you are asking about the benefits of going from Android to Xamarin.Android. In order to get here, the first question I’m almost always going to ask would be “why”?

The next question to ask is “is the project ‘new'”? In terms of “new”, this could be whether it’s new new, or this is scrapping the old codebase that there was once before, which is still being used, but replacing it with something that is to the point of a shareable workspace.

Because a couple of years before, it used to be that in order to use Xamarin alone, there was a fee. Therefore, it made more sense to just develop in a couple of platforms (mainly iOS and Android) because although iOS has always been $99 annually for renewing the developer’s license, in either case it was better to use the specific IDE that the device’s apps to build were designed for. For performance, this made the most sense. The drawback was that in business logic, there would be some that would have to be written twice both in Objective-C/Swift and Java/Kotlin.

Having said that however, Xamarin one of these days decided to become free. Therefore, in using Xamarin, the business logic can be written once and then run everywhere. The team doesn’t have to be as big either. Also, object-oriented programming principles still apply, along with learning curves of functional programming (but for old-timers, this isn’t a big deal). If you’re a learner, this is a big gain.

Let’s say that there’s a team of at least 3 in Android alone. This means having to split the cost for each person’s time, so then each developer will do certain tasks for the app alone. Copy this idea within iOS and now you have at least 6 people, which can get quite expensive fast. This is one reason why some startups don’t survive.

The next question to ask is whether or not the same app for both iOS and Android will have the same types of functionality, and also the formatting. It’s highly unlikely that the apps will have very different functionality, but if there is, then Xamarin will not be the ideal choice. But again, this is going to cost more for the logic, the backend development, and the mess that will be created. Therefore, I’d call this a loss, so the smarter choices will give better results.

Using Xamarin, one person can work on one platform. Then with any changes needed in shared code, multiple people can work on them. This makes the team smaller, and each person will learn about the different platforms of how they function. Questions will have to be asked. This is another gain for each developer using Xamarin.

Then, if the timing of design and development is done right, then the productivity should be a lot faster. This is for the company’s gain, but it also means your iterations will also look fast as well.

Finally, you’ll be sure that you’ll learn about your platform very well almost independently, and without having to rely on others. The only thing to rely on is Xamarin and its libraries that get maintained quite often.

But if you are just doing Android at this current time, I’d recommend trying Xamarin.Android for about 2 months and see how you like it.

Until next time!

Brian.

Hey everyone,

I’m sure that the majority of us have looked over on StackOverflow for solutions to a certain problem. I’m also sure that we’ve done a copy and paste at one point or another. I’m sure that there are those situations where we take the source and then try it, and the test works!

So, as anything in life, there are some good, and there are also some bad. So, the question is how do we understand that it is bad?

First of all, I want you to think for yourself in terms of sitting there, looking at the code to get a general idea of what it does, then looking deeper into the source level, and then see if it fits what you’re trying to achieve.

Do you see any potential problems aside of the solution posted on StackOverflow?

If you see a red flag, then I’d think of another solution that’ll be the “same”, but “better”.

In fact, I saw one today and thought to myself the solution wasn’t worth implementing since there seems like some potential side effects that I couldn’t fathom with. Moreover, it was also complicated, and there was also an edge-case that I know wouldn’t work with that. And because I already knew that I’m unable to use the solution, I started looking into making one that I’m much more sure of which will work.

It is all about analysis before getting something done. Whether it’s writing whatever you need down in chicken-scratch, looking deeper on the internet for more answers, or asking another person about a problem, this is all going to give your application good performance, and ensuring that you did it right!

I’ll give out an example, but that’ll wait until next time!

Brian.

Hey everyone,

So today, I was actually stuck on a problem for a long time. I’ve tried so many solutions that didn’t really help out. It was from looking at my own code where I wasn’t able to see anything wrong with it, towards listening to a task, down to rebuilding my view model again and disposing my listeners, down towards recreating my activity.

The last two options work pretty much the same way, with the exception of recreating all of your views and adapters (if any) which can be a much more expensive operation if you had to deal with many objects, versus dealing with maybe 4 or 5 items. Unless it’s better to do a recreation of an activity without worrying too much just as a page refresh, and if it takes at most 3 seconds to load the page, then that’s worth the change.

Anyhow, this post was more about being stuck on a problem. It turns out that the problem was laying under the shared code, and it was a boolean that was missing there that just didn’t provide the results for me on time!

Wow, now that’s not so easy to find. I had a second pair of eyes to take a look as well. And yes, although he had told me what I should try, I have already done most everything and it’s better just to say so. Therefore, it’s always better to know what you have done and then explain it as simplified as possible.

So that’s where the problem lies. Okay, I’m probably not too much of a genius, but I do know what I’ve tried. I also don’t want code that seems too complicated, or even spaghetti, otherwise it just seems like too much time and even trying to find out what each segment does.

However, that’s most of what our code looks like. But since I’ve learned to always try and simplify the code, it’s serving me quite well.

Therefore, remember that quality of work is always important. Otherwise, watch out and don’t let bad code pile up to a mess.

That’s all I have for thoughts, and until next time!

Brian.

Hello everyone!

Just as an update to say that I’ve been doing fine along with my ankle as of late. All that I haven’t done was follow up with the doctors.

Sure, the nurse practitioner might have said to me that I shouldn’t have been walking. However, I was already walking the next three days. Of course, the healing progression was slower, but even some of my colleagues told me not to worry about it, especially if I can handle it.

Granted that there are still some swollen places around the ankle, everything is walk-able and I’ll be expecting another two weeks until the ankle heals up fully. It is good that since we all work in the office using our keyboards, the foot doesn’t affect us as much! 🙂

Either way, I’m feeling great as things are turning out, so no worries there 🙂

Let’s get to the why I’ve got here. It’s all about the failure. Yes, failing is always going to be a part of life, and you need to do this in order to become better. Especially in programming since it takes around 6 months of continuous development to make something great. Specializing in one thing will also get you to dig down deeper into the why of something happening.

Therefore, if you’re failing at something, then just pick yourself up again and keep thinking about it. Draw it out if you need to. The key is “don’t give up”, and keep walking.

Until next time!

Brian.