Shadowing Practice: Why 95% of Android Developers Get Use Cases Wrong - Learn English Speaking with Video

בחר מצב תרגול

כל מצב פותח חדר תרגול במסך מלא.

78 משפטים

אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.

Hey guys and welcome back to a new video.

95% of Android developers use use cases wrong.

It's a catchy title, but I really mean that number.

I will tell you why.

Because use cases on Android and in software development in general are so often misunderstood.

I also myself misunderstood them when initially getting into these.

I'm pretty sure you can still find some super old videos on my channel where I'm also making the mistake

that I talk about in this video.

If your use case looks like this to get some user information, then you are doing it wrong.

Why is that?

In order to understand what use cases should contain and what kinds of use cases you should create, if you decide to stick to use cases,

we need to understand what a use case is originally meant to be in the context of software engineering.

And if we actually just Google for that, use cases software development, and we just click on a random picture here, then we have, for example, a library information system.

And then we have some use cases.

This is what we call a use case diagram.

Maybe you remember that from university or so.

to browse books, checkout books, return books, update the catalog, clicking here, view items, make purchase, checkout, client register.

If we carefully think about these use cases here, how they are named, view items, browse books, checkout books, what do all these have in common?

They all have in common that the user is actively aware about these things happening

because it is a real use case of your app.

And if you have a use case, then you can use it as a user.

Now, when we talk about email validation, is that a use case?

Is this something where a user would go to your app and now say, ah, now I'm going to validate my email, or now I'm going to clear my session.

Or hey, now I will retrieve a user by its ID.

No, they actually have no idea that these things happen.

These are rather just side effects of a real use case.

The user definitely knows that they are currently registering an account.

And email validation is just a side effect, something that happens as part of registering an account, but it's not something that the user actively has in their mind when they go through registration.

So if we take a look at some real use cases, the way it's really intended here on the correct, then we, for example, have this register use case.

And you can see suddenly it starts to contain real logic.

It's not just a single line of code that calls a repository or some kind of validation class, but it's a real use case that combines multiple pieces of business logic into a use case,

into something the user can do with your app that they are aware about.

So this would be a good example for a use case because the user knows that they are registering an account.

Of course, what's part of the use case is actually validating the email.

It's validating the password.

It is actually making the call to our remote API, for example.

It is then handling the errors and actually forwarding these to whatever class calls this use case.

That is a good example of a use case.

Well, let's take a look at this logout use case a user certainly knows that they are logging out.

But what internally happens as part of logging out, like actually making the network call, clearing the session, clearing their shopping cart, that's something they don't know and they don't have to know.

So the use case actually just bundles these function calls and makes sure that they are executed in the right order.

So we have a reusable kind of package for logging out and we just need to invoke the logout use case.

So other parts of our app also don't need to know what internally happens when we log out.

And all these other classes that act as utility for our use cases, like validating an email, this is of course still business logic.

This still lives in your domain layer, but it's not a use case.

So you really just make this a plain class, call it whatever it's responsible for, email validator, password validator, and then suddenly use cases make a lot more sense.

As you know, I'm usually not for using use cases a lot

because you will still often have these pretty much empty use cases, even when doing it the correct way.

So for example, if you say you want to fetch your nodes, so you actually want to see the nodes as a list, and then there's usually just a call to a REST API.

So you just forward this to your repository.

There's no error handling or so.

Maybe the repository already handles that, but no real business logic error handling in the use case itself.

But there are certainly use cases that make a lot of sense.

Like here, bundling these different calls here into a logout use case makes a lot of sense

because you will never again have to memorize what logging out really does in your app.

Instead, you just call this use case.

You never have to memorize what registration actually means and does in your app, unless you're, of course, responsible for working on that part.

But you can really just invoke the use case

and you know the use case involves the business logic to take care of that.

And if you stick to use cases in your app and you actually stick to them like this the right way, then I don't have a big problem with that.

Still, I personally lean more towards not using them at all

and just also bundling such business logic either in the view model or the repository, at least for small to medium-sized projects.

But for larger projects, this can make a lot of sense and I would also really consider having use cases there.

Now, if you feel like, okay, there is still a lot to learn about Android architecture, about Kotlin multi-platform architecture, then I can help you with exactly that

because we have our senior app developer mentoring where you get to build a real production project over multiple months

and have all your code reviewed by your personal mentors, including me.

This way we can spot issues in your app's architecture.

You actually have no idea about that these even exist.

If you're making mistakes you don't know of, then you obviously can learn from these mistakes.

So this is really a fast lane program here for you to grow to a senior developer level.

Link is below.

You can apply to this program.

We can have a chat if this could be a fit.

You can't just buy it on that website like a course, but we really first of all have to talk if we can help, how we can help, how it makes sense for you in order to also craft an individual learning plan for you.

So take a look at that.

Thanks for watching and I will see you back in the next video.

Have an amazing rest of your week.

Bye bye.

הורד אפליקציה

כל מה שאתה צריך כדי לדבר בשטף

הגיית AIציון לכל משפט

תרגול IPAשלוט בכל צליל

אוצר מיליםבנה את מאגר המילים שלך

משחק אוצר מיליםלמד תוך כדי משחק

סרוק QR

Download on theApp Store Get it onGoogle Play

אותו ערוץ

Wild times we live in

Daily ConversationWorking Adults

We will all be generalists.

Daily ConversationWorking Adults

FOR YOU

המלץ על סרטון

129 משפטים

אוצר מילים והערות הגייה לשיעור הזה

שיעור הדיבור הזה ברמה C1 מבוסס על הסרטון “Why 95% of Android Developers Get Use Cases Wrong”. המילים שחוזרות הכי הרבה: user, app, logic, email, example. בסרטון הזה יש 78 משפטים ו-1240 מילים לתרגול Shadowing. הדיבור נמשך 5:29. הדובר מדבר מהר, כ-226 מילים בדקה, אז צפו לצלילים מחוברים ומקוצרים. 87% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית; כדאי ללמוד את השאר לפני שמתחילים.

אוצר מילים מרכזי בסרטון הזה

8 המילים המתקדמות ביותר בסרטון, עם ההגייה והמשמעות שלהן:

מילה	הגייה	משמעות
memorize פועל	/ˈmɛm.əˌɹaɪ̯z/	שִׁנֵּן
mentor שם עצם	/ˈmɛn.tɔː/	מַנְחֶה, חוֹנֵךְ
password שם עצם	/ˈpæs.wɜɹd/	סִיסְמָה
fetch פועל	/fɛt͡ʃ/	הביא, השיג
diagram שם עצם	/ˈdaɪ.ə.ɡɹæm/	תַּרְשִׁים
catalogue שם עצם	/ˈkæt.əˌlɔɡ/	קָטָלוֹג
execute פועל	/ˈɛksɪˌkjuːt/	להוציא להרוג
cart שם עצם	/kɑɹt/	עֲגָלָה

Phrasal verbs שתשמעו

מילה	משמעות
log out פועל	הִתְנַתֵּק

הגייה ששווה לשים לב אליה

הדובר משתמש ב-13 קיצורים וצורות מקוצרות, כמו don't, I'm, you're. אמרו אותם בצורה הקצרה, כפי שאתם שומעים אותם.

מילים ארוכות — שימו לב להטעמה: repository /ɹɪˈpɒz.ɪ.t(ə.)ɹɪ/, validation /ˌvæl.əˈdeɪ.ʃən/, misunderstand /mɪs.ʌn.də(ɹ)ˈstænd/, internally /ɪnˈtɜːnəli/

צלילים שדוברי עברית מתקשים בהם:

/æ/ — פתוח יותר מה-“אֶ” העברית, לא כמו “a” ב-“cup”: validate /ˈvæl.ɪ.deɪt/, validation /ˌvæl.əˈdeɪ.ʃən/, misunderstand /mɪs.ʌn.də(ɹ)ˈstænd/, password /ˈpæs.wɜɹd/, catchy /ˈkæt͡ʃi/
/r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: repository /ɹɪˈpɒz.ɪ.t(ə.)ɹɪ/, memorize /ˈmɛm.əˌɹaɪ̯z/, misunderstand /mɪs.ʌn.də(ɹ)ˈstænd/, browse /bɹaʊz/, password /ˈpæs.wɜɹd/
עיצור קולי בסוף מילה — /b/, /d/, /g/, /z/, /v/ בלי להפוך אותם לאטומים: memorize /ˈmɛm.əˌɹaɪ̯z/, misunderstand /mɪs.ʌn.də(ɹ)ˈstænd/, browse /bɹaʊz/, node /noʊd/, password /ˈpæs.wɜɹd/

איך לתרגל עם הסרטון הזה

הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
התחילו במהירות 0.75×, תרגלו Shadowing משפט אחר משפט, וחזרו למהירות רגילה כשזה מרגיש קל.
הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו memorize, mentor, password.

מהי טכניקת השאדואינג?

שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.

טכניקת Shadowing: קרא את המדריך המלא שלב אחר שלב →

Shadowing Practice: Why 95% of Android Developers Get Use Cases Wrong - Learn English Speaking with Video

בחר מצב תרגול

הורד אפליקציה

Wild times we live in

We will all be generalists.

How to Become a Great Software Developer — Best Advice from Top-Notch Engineers

01 - Course Introduction - Shopify App development with Remix

Learn Marketing Case Interviews in 8 Minutes

Why we can't stop scrolling.

System Design Mock Interview: Design Facebook Messenger

#02 Common Pitfalls of building Human Resources Strategies

10 Usability Heuristics: From Theory to Practice | Course Preview

19 Phrases Native English Speakers Use Every Day

Most devs don't understand how LLM tokens work

The Lazy Method: How I Build $10K/Month Apps

The Technical, Business and UX Skills Every Product Manager Needs

Your API Can’t Handle Real-World Integrations