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.
He is a former child prodigy who entered college at the age of 12, finished his bachelor’s degree at 14 and his PhD at 20 years old.
Currently, Erik is 36 years old and is a computer science professor at MIT. You can find his lectures, books, papers and many more things on Erik Demaine.
Read Petar Nyagolov‘s answer to What happens to prodigy students? on Quora
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.
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 … 🙂
Notes:-
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#.
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.
Notes:-
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#.
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.
Reguirement:-
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.
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.
Notes:-
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#.
In this chapter we talk about :-
mmmm … but what does “great software” mean ??
There are some important concepts we should know :-
Notes in chapter :-
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#.
