xosnos / twitter

This is a basic twitter client app to read your tweets.

👋🏻 Hello World Universe, Steven here

👦🏻 About Me

const xosnos = {
  name: "Steven Nguyen",
  pronouns: ["he", "him", "his"],
}

🌱 Currently learning prompt engineering and back-end development.

🔭 Slowly developing side projects and content creation.

👯 Looking to collaborate on open-source projects and Web3 dapps.

🤝 Seeking help with project management and public speaking.

♿️ I'm interested in civic technology and software accessibility.

✍🏻 I write about my experiences and projects on

📫 You can reach out to me on

💬 Ask me about technical/behavioral interviews and self-development.

⚡ Fun fact: A huge part of my successes came from luck and support, so you'll find me doing a lot to give back to the community.

📚 Domain Knowledge

• Software Engineering
• Front-end Development (Web & Mobile)
• UI/UX Design
• Distributed Systems
• Cybersecurity
• Data Structures & Algorithms

🐥 Skills

📚 Learning

⌨️ Languages

🤖 Hosting / SaaS

🖼️ Frameworks, Platforms, and Libraries

💻 Servers

💽 Databases

🎨 Design

🛠️ Other

📊 Stats

twitter's Issues

Project Feedback!

Nice work! This week, we continued to explore how to build apps that use an API (like Twitter). Unlike the movies app, we created a new class called TwitterAPICaller to help us interact with the API. We're also starting to introduce Auto Layout, which is how you make your app work for different phone sizes. Now that you've finished the app for the week, it's good to reflect on a few things:

• Manual segue for the login button. Remember that we couldn't create a segue directly from the login button because we have to check the user's credentials. If they enter the wrong password (or the login fails), you don't want to segue to the next screen.
• UserDefaults. We used UserDefaults to keep track of whether the user was logged in or not. If they were already logged in, we went directly to the tweets screen. UserDefaults is a great place to keep track of things you want to save locally, but not save on the server. For example, if you want to show a popup message one time only, you could use UserDefaults to keep track of whether you've shown the popup message already.
• TwitterAPICaller. Go back to the project and look through this file that we provided. There are some functions related to authentication that you can ignore. Twitter uses OAuth 1.0a for authentication, which is an old standard. Most new APIs will use something similar to OAuth 2. Other than the authentication functions, the class is pretty simple, and you can create something similar to interact with other APIs.

Check out the assignment grading page for a breakdown of how submissions are scored.

If you have any technical questions about the project or concepts covered this week, post a question on our Discussions Forum and mark the question as type, "Curiosity". For general questions email us at, [email protected].

Project Feedback!

Congratulations on finishing the Twitter assignment! Twitter is an example of a RESTful API, and they generally follow the same pattern. It might be interesting to look at other APIs like Yelp, Foursquare, Google, etc. In a company (or your own app), you'll probably be working with a private API, but it'll also be structured like the Twitter API.

• Read more about HTTP requests. The most relevant parts for now are understanding the difference between GET, POST, PUT, and DELETE, and understanding how HTTP caching works.

Check out the assignment grading page for a breakdown of how submissions are scored.

If you have any technical questions about the project or concepts covered this week, post a question on our Discussions Forum and mark the question as type, "Curiosity". For general questions email us at, [email protected].

Project Feedback!

Nice work! This week, we continued to explore how to build apps that use an API (like Twitter). Unlike the movies app, we created a new class called TwitterAPICaller to help us interact with the API. We're also starting to introduce Auto Layout, which is how you make your app work for different phone sizes. Now that you've finished the app for the week, it's good to reflect on a few things:

• Manual segue for the login button. Remember that we couldn't create a segue directly from the login button because we have to check the user's credentials. If they enter the wrong password (or the login fails), you don't want to segue to the next screen.
• UserDefaults. We used UserDefaults to keep track of whether the user was logged in or not. If they were already logged in, we went directly to the tweets screen. UserDefaults is a great place to keep track of things you want to save locally, but not save on the server. For example, if you want to show a popup message one time only, you could use UserDefaults to keep track of whether you've shown the popup message already.
• TwitterAPICaller. Go back to the project and look through this file that we provided. There are some functions related to authentication that you can ignore. Twitter uses OAuth 1.0a for authentication, which is an old standard. Most new APIs will use something similar to OAuth 2. Other than the authentication functions, the class is pretty simple, and you can create something similar to interact with other APIs.

Check out the assignment grading page for a breakdown of how submissions are scored.

If you have any technical questions about the project or concepts covered this week, post a question on our Discussions Forum and mark the question as type, "Curiosity". For general questions email us at, [email protected].