Tag Archives: software development

10 Best Practices for Software Development

software development servicesRight Resources, Right Talent in Software Development

Hiring the right talent makes all the difference in the world when it comes to software development. When going through the hiring process you’ll want to make sure those you’re considering have the right skills and relevant experience to get the job done. This will enable you to allocate work to the appropriate person. Once the team members are in place, make sure they have whatever they need to put their expertise to the right use. From the correct software and hardware and the appropriate automated tools to the right development and testing software and platforms. Doing so will ensure that robust products are being created.

Consider Outsourced Teams

Sometimes outsourcing software development is more beneficial than trying to do everything in-house, and often costs the same or even less. In 2017, nearly one-third of companies outsourced their software development, and 78% of those companies felt good about making that decision. As with anything, there are best practices to implement and mistakes to be aware of when it comes to outsourcing software development.

First, we’ll talk about best practices to implement:

  1. Consider whether your project is right for outsourcing. Can someone else do it better than your team?
  2. Make a plan. Don’t just hand off a project without having a clear and detailed plan for what needs to happen and when.
  3. Look for a trusted provider. Vet whoever you’re planning to outsource to in order to ensure they can handle the work you’re giving them. Make sure they’re up to date on the latest trends relating to the project.
  4. Have a dedicated team. Even if you’re outsourcing a project, you should still have an in-house team to keep an eye on things. It doesn’t need to be a big team – a couple of people can manage the gig.
  5. Go Agile. Break the project into multiple iterations that are a few weeks each. Don’t forget to allow time for testing throughout the process.
  6. Pricing isn’t everything. Just because someone is offering a good price doesn’t mean they’re the right person for the job. You get what you pay for.
  7. Research and development. Don’t outsource a project without doing your homework.
  8. Document. Leave a paper trail no matter what.
  9. Communicate. Be sure to keep the lines of communication wide open with your team and the team you outsourced to.
  10. Own the project. Take ownership and be prepared to adjust along the way.

Second, we’ll talk about mistakes to avoid:

  1. Lack of research. Do your homework on the companies you’re considering outsourcing to. You want to be sure you choose the company that has a firm grip on providing software services.
  2. Unclear requirements. Be explicit about what needs to occur during the software development process.
  3. Not on-trend. You don’t want to outsource to a company that isn’t keeping up with modern trends.
  4. Lack of tech-savvy manager. You want the project manager to be ahead of the curve when it comes to technology.
  5. Don’t underestimate quality assurance (QA) and testing. These are two of the most vital aspects of software development.

Think About Your Development Process

When it comes to choosing a software development process, you have a few good options, including the waterfall model, the agile methodology, and the iterative spiral methodology. Choosing the best methodology for your project and strictly adhering to it will lead to greater success. It can also be helpful to create a prototype to study the feasibility of and explore new technology.

Don’t Forget to Budget

When it comes to budgeting a software development project, it’s not just about creating a financial budget. You also need to budget a schedule, resources, and efforts involved in the project. When creating estimations, you want to use proven techniques that won’t lead to a short-scheduled project. Not leaving enough time to complete each aspect of the development can quickly lead to disaster.

Keep it Simple

When it comes to software development, especially those projects that are being outsourced, it’s important to keep things simple. There’s no need to overthink it. Create processes and plans that will ensure the project runs smoothly and will keep the lines of communication open between your team and the outsourced teams.

Code, Code, Code

It’s important to keep the actual coding process as simple as possible. Max Kanat-Alexander came up with the idea of code simplicity in order to “reduce unnecessary complexity in software development.” Code simplicity works in tandem with Don’t Repeat Yourself (DRY) and You Aren’t Gonna Need It (YAGNI), both of which are mantras in agile development.

Effectively Implementing Code

When it comes to effectively implementing code, there are a couple of things you can do to make the process go more smoothly. The most widely used method is creating smaller modules that are coded and self-tested throughout the development process. Automating processes also helps ensure that functionality is not broken within the software being developed.

Test, Test, Test

We cannot stress this enough. Testing is vital to successful software development, especially if you’ve outsourced the development. If you’ve outsourced the project, be sure the company doing the development is testing along the way. You’ll also want to do your own testing when you get the final version before releasing to the public. If you’re doing the development, build testing into the development process so that you can make changes as issues arise.

Leaving a Paper Trail: Documentation

The documentation related to the software is just as important as the software itself, especially if you’re outsourcing the development. You want to have a consistent paper trail of communication between your company and the outsourced company to ensure there are no issues. Some important documents include a project plan, requirement specifications, high and low-level design (HLD and LLD), test plans and reports, status reports, and user documentation. This documentation can also be helpful if staffing changes occur at your company in the future.

Deploy and Review

Build reviews into your software development process. All deliverables, including code and documents, should be reviewed by both peers and experts. Having reviews of the software also ensures that there are no bugs before the software is released to the public.


Outsourcing software development has both benefits and pitfalls, but it can be done successfully if you follow the recommendations here and in our newest e-book, Santex’s Ultimate Guide to Development Outsourcing. If you still have questions or need more guidance, don’t hesitate to reach out; we have a well-rounded team who can assist with whatever your needs might be.Download Ebook Software Development


Why Agile Methodology is Good for your Business

agile methodologyAgile is something of a buzzword in the business world these days, but it’s not a complicated concept. At least, it doesn’t need to be. Agile coach Luis Goncalves lays it out really simply: “agile describes an alternative form of project management.” It’s also a process that helps teams do three things:

  1. Allows teams to provide a quick response to feedback.
  2. Creates opportunities to assess the direction of a project.
  3. Allows for assessment opportunities in team meetings called sprints.

An agile is also a very empowering process “that helps companies design and build the right product.”

Santex follows the agile methodology. This enables us to provide the best talent in the right moment, thanks to our high performing teams. This article will cover how to create high performing teams at your own company, how to have a happy team, and how to improve product quality.

The Importance of High-Performing Teams

Having a high-performing team is vital to being agile. Collaboration and communication are two important components of a high-performing agile team. Communication increases transparency within the company. When there is transparency, team members are empowered to do a better job. Keeping common goals and the company’s mission statement top of mind motivates team members to help the company succeed.

When a high-performing team is agile, there is no micro-management required. A high-performing team can be given direction at the beginning and trusted to perform well without a lot of guidance and hand-holding. Without micro-management, teams have the autonomy to let their talents shine and become stronger in areas where they might have been weak.

On an agile high-performing team, every member has a voice. They are given opportunities they might not otherwise have. Team members are given opportunities to explore their strengths and weaknesses, to provide input on various projects, and be a part of achieving the goals the team has set forth.

A Happy Team Is A High-Performing Team

Members of agile high-performing teams are able to contribute their best work, which also enables them to give customers exactly what they need when they need it.

Agile high-performing teams are also well-rounded, with everyone bringing a variety of skills to the table to achieve success. Agile teams are also able to anticipate product changes and prioritize efforts and features in order to be successful.

Having agile high-performing teams leads to happy teams who are able to produce good work on a consistent basis. A happy team is open to learning new skills, as well as going above and beyond to meet their customers’ needs.

Other important elements of a happy team include being engaged in processes and decision making, having buy-in with the company, and being able to work directly with stakeholders to get questions answered.

Happy teams prefer conversation to exhaustive documentation during meetings and other check-ins. This also leads to lower attrition rates. The team’s focus tends to be better due to the lack of micro-management and constant fire-fighting.

A happy team that isn’t being micro-managed is also likely to be far more productive. They now have the freedom to just put their heads down and get the work done.

Using Agile Teams To Improve Product Quality

When it comes to improving product quality, agile teams are much more capable of doing so because they have a vested interest in the product and the company. Agile for business means being able to drive real value, not just building a bunch of fancy new features.

Agile teams are also able to increase feedback, remove waste and roadblocks, and make code fully testable throughout the improvement process. They have a clearer understanding of what changes might need to be made because they’ve had buy-in throughout the entire process.

The testing and tweaking of products is integral to improving their quality. Products should always be evolving, especially in an effort to reduce the disappointment a client might feel when the product doesn’t do what they’re hoping it will do. An agile team values outcomes over outputs and ensures their products are addressing customer needs as accurately as possible.


If you’re looking to make your team more agile and high-performing in 2019 and beyond, Santex can help with that. Our e-book, “Best Practices for Software Outsourcing,” offers advice to help you with your software development needs. Furthermore, not only do we offer a range of resources to help your team achieve its goals, but we can also provide the best talent in the right moment, talent that can take your team to the next level and create agile, happy, and high-performing teams within your company, regardless of what your goals and mission are heading into the new year.

software outsourcing practices agile methodology

Why Does Your Company Need to Outsource Software Development?

Outsourcing software development is one of the most efficient ways to take your company to the next level. Outsourcing software development can increase profitability, improve your competitiveness in the marketplace, accelerate business operations, and, most importantly, increase customer satisfaction — and revenue along with it. With the right outsourcing team, your company will be ready to keep up with the demands of the ever-changing marketplace.

outsourcing softwareAlthough outsourcing software development is not a new tactic for product development, many companies still hesitate to seek outside help. However, when outsourcing is done right, the benefits of contracting a specialized team far outweigh the disadvantages.

Here are some of the top reasons you should outsource your software development needs.

Focus on your business

In today’s marketplace, team members often wear several hats and deal with many operations within the company. Your company’s IT department may not be able to put aside their current responsibilities to concentrate on a new project. Hiring and onboarding new developers can take months, but you have needs that must be addressed now.

Wise business managers know that their employees perform at their best when given the time to focus their efforts and plan accordingly. Stretching employees thin can affect team morale, productivity, quality of work, and employee retention. By outsourcing your software development needs, you are freeing up your team’s time to focus on what they do best. As a result, your product will be ready to hit the market faster, and with the best possible team behind it.

Software applications may play a key role in your business, but they may not be your core business. Entrusting your product development to a firm whose core business is software development ensures that you have access to growth strategies and operating processes which will be focused on creating high-quality software for your company.

Find talented resources and experience

For businesses looking to gain a competitive edge, outsourcing projects can open up access to technologies that may be unattainable otherwise. A software development firm can provide a pool of experts to take care of needs that your team currently cannot meet.

If certain programming skills are in high demand, the hiring pool for in-house employees may be limited. Conversely, if you need a niche technical skill or an innovative emerging technology, you may not want to commit to a full-time employee. Furthermore, the more specialized a skill, the fewer the people who will be available to execute it. You also may need subject matter expertise from someone who has worked on several similar projects and has the exact skill and technical profile needed to carry out your vision.

Outsourcing your projects means that you can expand your team to cover the exact skills and specialties required to develop your project. If a new demand or technical skill arises, the software development firm can easily cover those needs. If a team member is unable to work on a project, the firm can easily find a replacement, saving you time, resources, and money.

Save time and money

While costs should never be the most important factor of a business decision, the time and cost savings of outsourcing your software development may indeed convince you to search for an outside firm.

The costs of hiring and onboarding a full-time employee don’t end with a paycheck. In addition to the taxes and benefits (paid time off, health insurance, and 401(k) matching) that are provided on an employee’s behalf, additional costs of technological devices, hardware, software, office space, and direct management need to be taken into account when considering the costs of a full-time employee. Contracting a team to deal with a specific project may be more cost-effective in the long run compared to onboarding another in-house employee.

Furthermore, when it comes to outsourcing, the world is indeed your oyster. You can contract a firm from anywhere in the world, especially since much of the work and communication can be done virtually. As the cost of living varies throughout the world, the cost of outsourcing services varies along with it.

In today’s world, it can be challenging to keep up with the demands of the ever-changing marketplace. Outsourcing your software development projects can help your team members focus on what they do best, ensure that you find talented resources and expertise, and save time and money in the long run. In our e-book, “Best Practices for Software Outsourcing,” we offer more information about the factors to consider when outsourcing your programming needs.

At Santex, we are committed to your team’s success through our quality and passion. Along with building long-lasting and mutually beneficial relationships with our clients, our custom outsourcing services provide flexible solutions to meet your software needs. Software innovation is our passion, and our teams offer “the best talent in the right moment” to help you achieve your technology goals.

software outsourcing practices agile methodology

What to Consider When Hiring a Software Development Company

software development

It can be challenging to find the best software development company to meet your needs. There is often more to outsourcing that meets the eye, and choosing the wrong firm can cost you time, money, and your project’s position in the marketplace.

What are your project requirements?

Do you need to make a web application or a conventional website? Will the most complicated feature on this site be a blog or shopping cart, or will your project need to be integrated with a customized back-end system, such as an ERP or payment system? Do you have a maximum budget or a strict delivery timeline, or is having features your customers will love your biggest priority?

If your needs go beyond what can be found in a plug-in or a ready-made program, you need to find a software development firm with a wide range of expertise, such as software engineering, user interface optimization, web analytics, traditional web design, and more.

Furthermore, with many technical services, compromising on price may lead to a compromise in quality. If your application or project must be created from scratch, then the firm will probably need to construct something that the developers have never created before. Investing in a team with creative, flexible, experienced professionals increases your chances of getting the details right earlier on, allowing you to enter the market much sooner.

Here are a few tips to keep in mind to help the process of outsourcing your software development project go as smoothly as possible.

Proven track record

Although a firm’s portfolio may be impressive, it’s essential to know more about what happened behind the scenes. Even if the projects and web applications themselves look great, you have no way of knowing if these endeavors were delivered under budget and on time. The final project may have come to fruition only after constant conflicts between the software developers and the client. Asking for references now can lessen the chance of unpleasant surprises later, and an established company should have at least a few satisfied clients who would be willing to speak with you.

If a firm’s portfolio or client list is attracting you to a particular firm, you need to know whether the same software developers and engineers would also be assigned to your project. Make sure to ask about the specific developers who would be a part of your development team. When possible, ask for a reference from a client who has worked with these individuals before.

Maintain constant communication

Transparency is key in any client-provider relationship, especially if you are considering outsourcing a project to people you may never meet in person. In this digital era, the channels to maintain communication are as numerous the people who need them.

If you want to receive occasional updates and follow the progress with a project management tool, make sure the team and project manager are willing and able to use these tools. If you need frequent updates with details along the way, make sure that the project manager knows this and budgets time for these conversations. If the software developers use their own particular process, consider using their tools to ease the process.

Regardless of the exact process and tools of communication being used, your team of developers should be able to provide clear milestones and delivery dates, as well a list of their requirements from you.

As your project and relationship with the firm are coming to an end, determine what type of assistance, if any, you will need once the final project has been delivered. Will you be able to contact the firm once the application is up and running? How many iterations are included in your package? Will you be given the source files once the project is over?

The source files, such as descriptions of your database structures, access to code repositories, login credentials for site hosting, and Photoshop and Illustrator files, are essential to maintaining full ownership of your project. If you hope to make even one slight adjustment to your project in the future, ensure that your contract is transparent about the delivery of the source files upon completion of the project.

Finding the best software development company for your needs should not be taken lightly. In our e-book, “Best Practices for Software Outsourcing,” we elaborate on the factors that your company should take into consideration when looking to contract your project or web application to a software development firm.

At Santex, our software technology professionals abide by the values of participation, trust, passion, and courage when building a relationship with our clients. Our multidisciplinary teams are constructed with the goal of having “the best talent in the right moment,” and our business model prides itself on being able to provide flexible, creative solutions to meet your needs.

Software Outsourcing Santex

Things to keep in mind before adding a Software Dependency to your project

By Agustin Aliaga, Mobile Developer at Santex

Adding software dependency to your project – web frameworks

In my work experience, one basic thing I have learned about software engineering is that you don’t need to “reinvent the wheel” every time you want to achieve some new level of functionality. Open source projects have revolutionized the way we work in that we can reutilize existing software in addition to collaborating with others developers. In the web-development ecosystem, there are plenty of frameworks and tools that already simplify things like user authentication, routes, templating (client-side and server-side), state-management, database queries, web sockets, etc. On the other hand, however, sometimes the existing solutions just are not good enough. It may also be that there are no alternatives at all, but that’s a completely different story.

The ability to know when to implement the feature yourself and when to use an existing solution will be a crucial asset for your team. Adopting a new library, language, or technology as a dependency to building your product without extensive research could become a headache in the future, so you should always ask yourself these questions before making any decisions:

1. Does it meet all your needs?
Sometimes you’ll find a solution for your problem that does not cover all the specific features you need. In that case, you might have to deal with forking and extending it (if it’s an open source project), and this means greater time investments and costs. Are your team and the client prepared for this scenario?

2. Is there any documentation?
If so, how expansive is that documentation? Just as an example, one of the things I like the most about Django (web framework) is the quality they put into the documents. It’s remarkably easy to find the topics you need for the framework version you’re using. You can see more at https://docs.djangoproject.com/en/.

3. Is it supported by a “big” community and/or a private company? Having a company or a community behind the project helps a lot when you’re having trouble and need assistance from others. You may have to send a “help-desk” ticket (this will definitely be the case if it’s a paid service), find information on blogs or StackOverflow, or maybe even post a question to those sites. If you’re relying on the community to help you, your chances of being helped are proportional to the popularity of the software dependency.

4. Is it an “external service”?
If you rely on services like “Google Maps API,” “Facebook Graph API,” “Google’s Firebase,” etc. be aware that they may change in the future without notice, or they could just stop working at any time (temporarily or permanently). SaaS/BaaS solutions are great but you should think twice before setting them up as a critical piece of your system. Just as an example, you can read about what happened to Facebook’s Parse at https://techcrunch.com/2016/01/28/facebook-shutters-its-parse-developer-platform/.

5. Is it actively maintained and improved?
If hosted on Github, the “Pulse” and “Graphs” tabs will give you an idea of the latest activity. You probably don’t want to set up an outdated library, because it could bring retrocompatibility issues to your project. Also, if it’s constantly evolving, it could mean you’ll have to update your code repeatedly.

6. Is it tested?
Some libraries use automated tools to build and test every change that is introduced, such as applying continuous integration tools like Travis CI, Circle CI, etc. Doing this makes the library more reliable.

7. Are you compromising another dependency if you adopt this new library?
Sometimes libraries don’t play well together.

8. Will it affect your product’s performance, speed, size, etc.?
You should always take this into consideration. In the “web environment,” a giant front-end library could affect the browser’s performance and also increase network transfer times. On the back-end side, you want to avoid server overloading. In the mobile world, things get even more critical because mobile phones don’t have as many resources as a desktop computer does. In Android, an app that wastes memory and CPU is a very likely candidate for being killed automatically by the operating system.

What about Android ?

The core-functionalities that Android brings to the table are sometimes more than enough to build simple applications. You could build an entire app by using bare Activities, Fragments, Views, AsyncTasks, Services, Content Providers, Broadcast Receivers, etc.

But in my experience, sometimes this means you’ll have to write (and then maintain) a lot of repetitive and boilerplate code. In other words, sometimes sticking to the core framework means you will have to invest more time in taking care of all the details. Some examples of libraries that made me more productive in Android development are Retrofit, Dagger 2, and Butter Knife.

You should also know that if you add too many direct and transitive dependencies (plus your own code), you might exceed the “64K-method limit,” explained by Android documentation:

Android app (APK) files contain executable bytecode files in the form of Dalvik Executable (DEX) files, which contain the compiled code used to run your app. The Dalvik Executable specification limits the total number of methods that can be referenced within a single DEX file to 65,536, including Android framework methods, library methods, and methods in your own code. In the context of computer science, the term Kilo, K, denotes 1024 (or 2^10). Because 65,536 is equal to 64 X 1024, this limit is referred to as the ’64K reference limit.’”

If you exceed this limit, you’ll have to change your application to support “multidex,” which means it will have to load multiple dex files. This will produce higher compilation times, and also performance and loading issues in the app itself. So I’d recommend to always be careful with the dependencies that you add to your Android project.


I have seen these concepts apply not only to Android development (a technology I use every day at work), but to all software development in general. Every product relies on dependencies (whether it’s an OS, a service, a framework, a library, or some other kind of software). The goal is to pick the best ones to maximize your productivity, without affecting your product’s performance, scalability, and capacity to evolve over time.

When Not to Use Drupal

By Sebastian Gonzalez – Drupal Developer at Santex

 Drupal website or project: when not to use the tool.

First off, I would like to clarify that I love to work with Drupal. I’ve been working with the Drupal platform for about 10 years now and, through all those years of getting frustrated over the same things, I realized something. I noticed that when certain clients or businesses had a previous project in Drupal that was successful, they would want to handle any future projects in the same way, when in reality Drupal may not have been the best tool to use, depending on the project.

In all these years of experience, I have come across various projects and had a lot of different experiences, some that were very rewarding and others that were less rewarding. In some of the more recent, less successful projects, I noticed that something kept repeating itself. Drupal was being used for a variety of projects on the premise that “it can do everything.”

If a client needs to create any sort of app, developers usually say that Drupal is the solution. But what we should say is that Drupal could be the solution. Changing the message from “Drupal can do that” to “Drupal should be able to do that” is fundamental to starting any project off on the right foot.

Drupal is a CMS (Content Management System) that was intended to be a content administrator. Every page in the world has content, and when we talk about ‘content,’ we automatically think that it should be able to be handled administratively. This leads one to automatically think of a CMS like Drupal, WordPress, or Joomla. For me, the important question is what you want to do with the content. Where is this going and what is it going to be used for?

A lot of people view Drupal as a CWMS (Content Workflow Management System), and I agree with this vision. In my opinion, it makes sense to use Drupal when a business’ domain entails a lot of different types of content with multiple users who have different permission levels. All of these users can alter the state of the content, making it fluctuate through different phases of the workflow where there aren’t annotations, reports, or emails involved.

The reality is that the vast majority of websites built using Drupal should not have used Drupal. This is not because Drupal can’t do the job, but rather because it’s a waste of all the functionalities that end up not getting used. A clear case of this is with classic brochure websites or institutional sites where the content is static and hardly changes over time. There isn’t much interaction between users beyond basic contact forms or a comments section.

Our world is currently dominated by mobile devices. Drupal was able to enter into the competition with its latest version, version 8, which came out in November 2016. Using and integrating components with the popular framework Symfony provides a robust back-end to facilitate API development. Drupal is jumping into this trend with something called Headless. Headless is an architecture that uses Drupal as the back-end paired with a framework to present the data, which could be AngularJS, React.js, or any other framework.

In summary, I believe Drupal should not be used for:

  • Simple brochure websites
  • Single-purpose apps (like a chat application)
  • Gaming apps

I think Drupal should be used for:

  • News websites with multiple users
  • Multi-user publishing apps
  • Any app or website that includes workflows among people with different roles/permissions
  • A mobile version for Drupal

To conclude, here are four more pieces of advice:

  • Choosing one tool over another has to do with understanding the business’ control over the application or website. The more you know about the project, the greater the decision making power in choosing which platform to use to meet those needs.
  • Use Drupal from the start. Don’t try to switch and start using it for something else when things are not properly in place.
  • Stop saying “Drupal is the solution” and starting saying “Drupal could be the solution!”
  • Always explore alternatives because new technologies are coming out everyday.



About the Author – Sebastian Gonzalez is an experienced Drupal Developer at Santex,  passionate about his work.  Sebastian is a strategic team player always willing to contribute and to solve problems.

What Thread, Main Thread? Part II

By Martín Zangl – Android Developer at Santex


If we are to understand some basic, common behaviors for approaching a simple solution using threads, we know that at some point we have to manage communication and execution order. For that, Android provides us with a variety of concurrency and communication frameworks that are designed, implemented, and integrated in accordance with many of the patterns that you can find in POSA books.

Android provides different tools according to concurrency patterns:

We can resolve many problems with one or more of the following:

  • Using handlers and other threads
  • Asynctasks
  • Loaders
  • IntentServices

Custom Handlers and Threads

As previously stated, there is only one Looper per Thread, but we can also have different handlers post messages and process them.

For example, we could define two threads with two handlers to send messages to each other.

Using Android threads

For instance, what if for one of the threads in the Main Thread, we could send update messages to UI widgets and notify them of something that happens in the other thread? Remember, if we are just using a simple pattern like an observer pattern and notifying every change directly to the UI, it won’t work because we are trying to change the state of view object from a thread other than the main thread. In that case, we could post the result or intermediate results on the handler registered to the main thread. In other words, we have an Activity, we declare a new Handler, that handler would be associated to the Main Thread, that is, the main looper, so every time we send a message from another thread, the handler will post the message in the message queue, then the looper will process that message by sending it to the registered handler. Then we can update some UI widgets.

This is a pretty clean solution, but it becomes very difficult to handle the UI widgets’ lifecycle. That is to say, when a configuration change happens or when the user changes the context often.

The worst case scenario is when a configuration change happens, because in that case a new instance of the activity will be created. It would be even worse if we had references for any particular view on those messages; in that case the reference cannot be garbage collected and we’d just be leaking memory.

More in detail, every time that a configuration change happens two new messages are posted to the looper queue, one is CONFIGURATION_CHANGE and the other is RELAUNCH_ACTIVITY and this is what happens after that message is processed:

  1. calls onSaveInstanceState(), onPause(), onDestroy() on the old activity instance.
  2. create a new activity instance.
  3. calls onCreate() and onResume() on that new activity instance.

In the case of sending messages from other threads to the main thread, we have to be careful. We cannot predict in which activity instance we are posting those messages.

We could do some speculation and think if any message posted before the orientation change would be handled before onPause() the leaving activity, and if any message posted a after the orientation change will be handled after onResume() the incoming activity.

 What can we do?

Fix the architecture instead of messing it up with handler.post().

Do not hold view or context references.

Remove all messages or callbacks in the activity onPause()

And the last one if you want to get fired use handler.postAtFrontQueue() to make sure a message posted before onPause() will be handled before onPause().

In the next post we’ll talk about Asynctask, IntentService, and Loaders.

About the Author – Martín Zangl is an experienced Android Developer at Santex,  passionate about his work.  Martín is continuously learning and training to investigate new technologies.



What Thread, Main Thread? Part I

By Martín Zangl – Android Developer at Santex

Using Android threads

Public Static Void Main

As we know, every single Java app starts with a call to method public static void main(). This is true for Java desktop, JEE servlets, and Android applications.

When Android boots, it uses a simple process called ZygoteInit. Zygote (Wikipedia) is a cell that can divide asexually by mitosis to produce identical offspring. This is a VM Dalvik process that loads the most common classes of the Android SDK on a thread, and then waits. When starting a new Android application, the Android system forks the ZygoteInit process. The thread in the child fork stops waiting and calls ActivityThread.main().

Here is what it’s essentially doing:

public class ActivityThread {

public static void main(String... args) {




Looper? What is a Looper?

Here we find a particular concurrency pattern called Thread-Specific Storage. This pattern allows multiple threads to use one “logical global” access point to retrieve an object that is local to a thread, without incurring locking overhead on each object access.

Android Thread-Specific Storage pattern

When an Android application starts, it creates a Looper object. A Looper object contains a static ThreadLocal object, a Message Queue, and the Thread reference that created it. In other words, a Looper implements a Thread-specific event loop. Using a Looper is a good way to process messages serially on one Thread.

Looper.prepare(); This operation associates the Looper with the current thread and stores it in a static ThreadLocal.
Looper.loops(); Will process each message in the queue, and block when the queue is empty.

As previously said, each Looper is associated with one thread. To retrieve the Looper associated with the current thread you can use the method Looper.myLooper().

An example of using a Looper with a Thread:

class HandlerThread extends Thread {
Looper looper;
public void run() {
looper = Looper.myLooper();

Handlers is the natural companion to a Looper. Looper has a Message queue and Handlers put messages or runnable objects in place and process each of them, i.e. it allows them to send messages to a Looper message queue from any thread and handle messages dequeued on the thread associated with that Looper.

You can associate many handlers to one Looper. The Looper delivers the message to one specific handler.

A default Handler constructor associates it with the current thread and its Looper. We could define the other Looper, if we want, in order to post messages to the Message queue of whatever Looper we want.

The Looper referenced in the void main method is called Main Looper, part of the Main Thread. This particular thread is in charge of dispatching events to the UI widgets that include the drawing events. All components (other Activities, Services, Broadcast Receivers, and Content Providers) that run in the same process are referenced in the Main Thread.

When an application performs intensive work in response to user interactions, this single thread model can yield poor performance. If everything is happening in the Main Thread it will block the whole UI, so no events can be dispatched, including drawing events. That is when a ANR (Application Not Responding) dialog appears. In that case, we just put all the long background operations in another thread, but other problems arise in paradise, only the main thread can process UI widgets. So, we need to somehow handle communication between threads.

In the next post we’ll talk about:

Using custom handlers and other threads

About the Author  – Martín Zangl is an experienced Android Developer at Santex,  passionate about his work.  Martín is continuously learning and training to investigate new technologies.


Extreme programming… once again

By Jose Torres – iOS Software Engineer at Santex

Extreme Programming principles help us safely drive the work of building software.

Vague or constantly changing requirements are a fact of life. Instead of ignoring them, we should adapt our processes to reality. Extreme Programming (XP) principles exist to help us safely drive the work of building software. The web is full of information on XP, which can be synthesized as:

Lightweight, evolving, flexible knowledge to develop software.

The concept of XP first came about in the 1990s. It bears repeating though, because, unfortunately, many organizations have lost the point. Perhaps they apply technical principles and fail in their flaccid adaptation. Maybe they employ agile processes but little in the way of technical practices. Can these discrepancies be balanced? How can we fight back?

Move to an extreme state and embrace its principles. Some organizations resist this shift. One of the best ways to adapt to this change is by running a pilot of a small, internal project.

XP Principles state that at least two developers must work in a single workstation. To extend this concept, add one more step after the development sprint organization and consider having the team determine the number of developers who will work together for each user story. On the most critical user stories, place the whole team at a single workstation to discuss and then write production code.

XP Principles also dictate that there be a short release cycle for the product. To take this concept further, set up a specific time period during the day (i.e. every three hours) to continually release the product. You could also consider a full integration, if possible. This will help relieve the problems of production integration later, as integration is always happening. As David Farley states “reduce cycle time and the rest falls out.”

Keep in mind that having an active local community can help you to go further. In London, for example, there are multiple extreme programming initiatives like XProlo, eXtreme Tuesday Club, and XPDay, all of which are dedicated to XP practices, where people can join and share knowledge. We should continue creating initiatives and networking to create communities and evolve together.

There are many ways of actively moving forward when integrating extreme principles in software development. As main actors, we are responsible for tracking the efforts of our organizations as they assimilate and take real XP practices to the next level.

About the Author
Jose is an innovative Software Engineer who specializes in developing iOS applications for both iPhone and iPad. Skilled in creating business applications as well as games, Jose enjoys mentoring colleagues and fellow developers.