Android Developer Path

Udacity has launched an Android Developer Path Guide. If you are newbie or have some experience with Android, take a look to that map to know the skills that you lack.

There are 3 levels in Udacity for Android developers:

  1. Beginner
    1. Android Basics: User Interface
    2. User Input
    3. Multi-Screen Apps
    4. Networking
    5. Data Storage
  2. Intermediate
    1. Developing Android Apps
  3. Advanced
    1. Advanced Android App Development



Share Android App Internal Storage Data

Two weeks ago I faced a problem, I was storing a pdf file in internal storage and I wanted to share it via another apps like Gmail, or any other sharing app. When I tried to attach it to Gmail for example I got this error “Permission denied for the attachment“.
The problem is that data saved in internal storage isn’t accessible by other applications.

After a while I figured it out, that the solution is in Content Providers.

Content Providers have a lot of uses one of them is providing a way to share data with other apps.

In manifest we declare the content provider :


name attribute is my custom content provider class, authorities attribute is URI that identify data offered by the content provider, exported is true means that the content provider is available for other applications to use.

After that we create our CustomContentProvider :


Finally, We will use our custom content provider to share our pdf file :


CONTENT_URI means I am going to use content provider “content://” + provider’s_authority + “/” + absolute file path.

That will allow our app to share the pdf file.

Chapter 4

In this chapter we talk about :-

This chapter is all about making sure that your software works in a real-world context.
Analysis: is figuring out potential problems, and then solving those problems before you release your application
out into real world.

In this chapter he talk about some notes in Class Diagram let’s see it … 🙂

1) Delegation helps our applications stay loosely coupled.That means that your objects are independent
of each other.

2) The nouns in a use case are usually the classes you need to write.
3) The verbs in your use case are usually the methods of the objects.

4) Think about how the classes you do have can support the behavior your use case descripe.
5) Pay attention to the nouns in your use case, even when they aren’t classes in your system.
6) Write your use cases in a way that makes sense to you, your boss, and your customers.

7) Association: means that one class is associated with another class by refrence,extension,inheritance,…etc
8) There are some important key words:-

Finally the source code for Modified Dog Door System that he talk about it in this chapter you can find it Here. I implement it in C#.

Chapter 3

In this chapter we talk about :-

In the real world requirements are always changing, and it’s up to you to roll with these changes and keep your customer satisfied.

When your customer has new need, it’s up to you to change your application to meet those new needs because

The one constant in software analysis and design is

Requirements always change. If you have got good use cases, though you can usually change your software quickly to adjust to those new requirements.

1- The Main Path should be what you want to have happen most of the time.
2- The Alternate Path is one or more steps that a use case has that are optional, or provide
alternate ways to work through the use case.
3- A complete path through a use case from the first step to the last, is called a scenario.

4- Any time you change your use case, you need to go back and check your requirements.
5- Duplicate code is a bad idea.
6- The last note is

Now we will add some new tools that we learn it in this chapter:-

And the OO Principles that we learn:-

Finally the source code for Modified Dog Door System that he talk about it in this chapter you can find it Here. I implement it in C#.

Chapter 2

In this chapter we talk about :-

mmmm …. but what exactly is a “requirement” mean ??

In this chapter we will learn how to satisfy our customers by making sure what
you deliver is actually what they asked for.

is a singular need detailing what a particular product or service should be or do.

1) Listen to customer:-
when it comes to requirements the best thing you can do is let the customer talk,and pay attention
to what the system needs to do,you can figure out how the system will do those things later.

2) Creating a requirement list:-
based on the custmer needs we create a requirement list.

Use Case:-
is the steps that a system takes to make somthing happen,and it is a technique for
capturing the potential requirements of a new system.

  • each use case provides one or more scenarios that convey how the system should
    interact with the end user or another system to achive a specific goal.

There are three basic parts to a good use case:-
1) Clear value:
every use case must have a clear value to the system(which means it should help the customers to achive their goal)

2) Start and stop:
every use case must have a definit starting and stopping point.

3) External initiator:
every use case is started off by external initiator ,outside of the system. it could be a person or anything outside the system.

1- Working applications make customer happy. 🙂

2- Here are some key tools for making sure your customers are smiling when you show them the systems
you have built :-

3- Be careful! Good use cases make for good requirements, but a bad – or incomplete – use case can result in Bad requirements.

4- Your system must work in the real world … so plan and test for when things go wrong.

5- There are some important key words :-

Finally the source code for Dog Door System that he talk about it in this chapter you can find it Here . I implement it in C#.

Chapter 1

In this chapter we talk about :-

Great Software

mmmm … but what does “great software” mean ??

what great software mean ?

  • Great software always does what customer wants it to. So even if customer think of new ways to use the software, it doesn’t break or give the unexpected results.
  • Great software is code that is object-oriented. So there is not a bunch of duplicate code and each object pretty much controls its own behaviour. its also easy to extend because your design is really solid and flexible.
  • Great software is when you use tried-and-true design patterns and principles. you have kept your objects loosely coupled, and your code open for extension but closed for modification. That also helps make the code more reusable, so yup don’t have to rework everything to use parts of your application over and over again. 🙂

There are some important concepts we should know :-

  1. Flexibility :  1) Enable software to change and grow without constant rework.  2) Keep Application from being fragile.
  2. Encapsulation :  1) Keep the parts of your code that stay the same seperate from the parts that change.
  3. Functionality :  1) Make the cutomer happy and puts a smile into customer’s face. 🙂
  4. Design Pattern :  1) Enable reusability and make sure that you are not trying to solve a problem that someone else has already figured out.

Notes in chapter :-

  1. Don’t create problems to solve problems.
  2. Use textural description of the problem you are trying to solve to make sure that your design lines up with the intended functionality of your application.
  3. Objects should do what their names indicate.
  4. Each object should represent a single concept.
  5. Encapsulation allows you to group your application into logical parts.
  6. Any time you see duplicate code, look for a place to encapsulate.
  7. Delegation :  is when an object needs to perform a certain task and instead of doing that task directly , it asks another object to handle the task.

Finally the source code for Guitar System that he talk about it in this chapter you can find it Here . I implement it in C#.